Hacker Debugging Uncovered Chapter 9:Hashing and How to Overcome it Chapter 10:Popular Protection Mechanisms Used in Demo Versions 2008.3.10 이동현

Chapter 9: Hashing and How to Overcome it

Intent 1980년대 후반 복잡한 패스워드 암호화 에 대한 응용프로그램 개발자의 첫 번째 시도. 1980년대 후반 복잡한 패스워드 암호화 에 대한 응용프로그램 개발자의 첫 번째 시도. 그러나 최신의 디버거와 디스어셈블러로 무장한 크래커 들에겐 불충분.  해시함수의 사용 시도 조차 불충분. 크래커들은 유효한 패스워드 입력을 위해 실제 패스워드를 찾는 대신 결과 해쉬값을 취함.    Listing 9.1. The evolution of protection mechanisms  if ((s==ch) != "KPNC")           cout << "password fail" << endl;   //Old variant  if (hashe(&pasw[0]) != 0x77)     cout << "password fail" << endl;   //New variant  둘 다 하나의 조건 분기를 변경 함으로서 충분하다.( 크랙 가능 )

부실한 보호 메커니즘의 이해 보안 개발자들의 부주의함을 이해하기 위해서 이들을 크랙 해보자. 모순되게도, 대부분의 프로그램들이 이런 순진한 방식으로 보호가 되어있다.  왜 프로그래머들은 좋은 의도를 가진 해커들의 조언을 듣고 자신의 실수를 고치려고 하지 않는지 참 수수께끼다.  잘 디자인 되고 구현된 보호 메커니즘은 비용이 많이 든다. 그리고 잠재적 고객의 구입을 증가시키지도 않는다.  어떠한 보호 메커니즘도 뚫린다. 유명하면 유명할수록 더 빠르게. 

Crack02.exe 기존방법으로 스트링을 찾아보자.. 안 보인다.. crack02.exe 를 dependency 로 추적. 음.. 좀더 자세히 살펴보면.. 리소스 안에 위치하고 있군..  그렇다면 LoadString 로 스트링을 불러왔겠군.  crack02.exe 를 dependency 로 추적.  음? 이놈이 LoadString 를 임포트 하지 않네?  의존하는 dll을을 추적해보자.. CString 가 호출하는군..  음 MFC42.dll 의 임포트 테이블을 덤프 해보니 심볼은 없고 Ordinal 만 있다. 맵 파일을 참고하자. MFC42.map  LoadStringA 의 주소로 툴을 이용해서 가보자.  코드의 생김이 함수 호출과 비슷하다.  자 이주소 0x5F404042 - 0x5F400000(loaded address) = 0x4042 ( map 파일 확인.. ) 모든 것은  IDA-Pro 를 이용함으로써 쉽게 해결.  이로서 Protection mechanism 의 시작지점을 찾았다. 마지막 점프 지점을 무조건 점프 명령으로 교체함으로써 손쉽게 Crack 되었다. 

Crack03.exe Crack02 는 너무나 쉽게 뚫린다.( 단지 한 바이트의 수정으로 ) 이 Protection Mechanism 을 개선 해보자. 패스워드를 프로그램 자체내부에 암호화 해서 내장한다.  툴을 이용해서 실행파일에 암호화된 패스워드를 저장하는 것도 가능하지만 직접 소스 코드에 암호화된 패스워드를 넣자. 

Crack03.exe 계속 마지막 jz 를 무조건 분기로 교체. 결과적으로 어떤 패스워드를 넣던지 프로그램은 받아 들인다. 그러나 정상적으로 동작하지 않음.

Crack03.exe 계속 입력된 패스워드가 사용되는 곳에 집중하자. 401291 번지가 핵심 SecretString[pTxt++] = SecretString[pTxt] ^ Password[pPsw++];

Crack03.exe - 계속 SecretString[pTxt++] = SecretString[pTxt] ^ Password[pPsw++]; 잘 알려진 Vernam cipher 이다. 소스 참고 if (mult(hashe(&pasw[0]),hashe(&pasw[0]))!=504) s0.LoadString(IDS_WRONG); 이 암호 체크 로직을 분석해 내야 한다.

Chapter 10:Popular Protection Mechanisms Used in Demo Versions

어떤 것들? Limiting the Functionality Limiting the Term of Use Limiting the Number of Startups The Nag Screen The Key File

Limiting the Functionality Cracking the program that requires registration doesn’t cause any difficulties. The demon version VS fully functional version. Physically missing. Cracking is impossible. Reconstruction of the missing code? You should study the algorithm of interaction between the remaining and the missing code. Usually the required code is physically present but never gains control.

Crack0d.exe 아주 간단한 시도 프로그램 제작 시 리소스 편집기에서 활성화 옵션을 비활성화 한 경우

Crack0e.exe Crack01 보다 까다로운 경우. 컨터롤의 활성화 여부와 상관없이 내부 플래그를 이용해서 등록 여부를 검증. 외부에서 리소스 편집기로 컨터롤만 활성화 시키는 걸로는 정상적인 동작을 수행할 수 없다. 리소스 편집기로 컨터롤 활성화 불가능. 프로그램 시작 시 API 를 이용한 비 활성화. Customizer 등으로 활성화 시도 후 아래 절차 시도.

Crack0e.exe - 계속 시도 “This is an illegal.. “ 메시지 검색. 프로그램을 제어하는 변수를 찾는다. Esi 는 클래스의 인스턴스이고, 원하는 변수도 같은 방법으로 초기화. 컴파일러의 최적화 등의 경우 아주 어려운 작업이나, 많은 경우 효과적이다. Esi + 제어 변수를 찾아서 수정 후 수행. 성공!!60 어떤 보호 알고리즘의 분석 없이 한 바이트의 수정만으로 Crack 성공. 기존의 보호 알고리즘 등은 모두 정상적으로 동작한다. 광범위하게 알려지고 사용되어지는 방법. 엄청난 양의 코드를 분석하고 회피를 위해 점프하는 등의 기법에 비해 훨씬 쉽다.

Crack0f.exe Crack0e 예제의 경우 하나의 제어 변수만 존재 했었다. 그러나 이러한 제어변수가 여러 개로 구성되고, return SomeResult*(!FlagReg1 ^ FlagReg2); 와 같은 로직으로 체크가 된다면 기존의 시도는 실패한다. 다행히 프로그래머들은 게을러서 이러한 바이트들을 신중하게 관리하지 않는다.

Crack0f.exe - 계속 첫번째 시도. 또 다른 원인이 어딘가 존재한다. EnableWindow 를 찾는다. 두군 데의 컨터롤 변수를 수정한다. 버튼은 활성화 되었으나 정상 동작하지 않음. 또 다른 원인이 어딘가 존재한다. 다행히 컴파일러는 이런 조각들은 가까이 배치하는 경향이 있다. – 이는 Cracker 의 일을 줄여준다. 주위의 다른 변수의 값을 변경해 보았다. 빙고~ . 제대로 동작하는 결과 출력. 보안 알고리즘은 세 개의 플래그를 사용하는 로직 이었다. S0.SetAt(0, s0[0]*(!RegFlag_1^RegFlag_3)); 제 4, 5의 제어 변수가 없다고 어떻게 장담하는가? 보통 제어 변수는 전역 변수이고, 잘 설계된 OOP 언어에서는 이런 변수는 거의 없다. 모든 건 개발자가 게으르다는 데 있다.

Crack10.exe 존재하는 기능을 막아둔 프로그램의 Crack 은 상대적으로 쉽다. 이전과는 달리 demo 버전의 프로그램에서는 특정 기능의 코드가 물리적으로 존재하지 않을 때 어떻게 하는가? 또한 컴파일러는 사용되지 않는 코드는 제거해 버린다. 결국 최종 실행파일에 해당 기능의 코드가 존재할 가능성은 없다. 보안개발자가 행복해지고, Cracker 가 불행해 지는 순간이다. 그러나 이 프로그램의 경우 해당 텍스트 버퍼에 접근이 가능하다면 새로운 기능을 추가 하는건 어렵지 않다. BOOL CCRACK10Doc::OnSaveDocument(LPCTSTR lpszPathName) { // TODO: Add your specialized code here and/or call the base class AfxMessageBox("This is a limited version. Please purchase fully functional one"); return 0; // AfxMessageBox("OK"); // return CDocument::OnSaveDocument(lpszPathName); }

Crack10.exe - 계속 문제점 고려 사항들. Import table 의 수정. PE파일에 새로 작성한 코드를 삽입하는 일은 아주 어렵다. 이전에 축적된 DOS 와 이전 Windows 에서의 지식은 쓸모가 없다. 그러나, Windows 는 DLL을 통한 코드의 수정이라는 방법이 있다. 고려 사항들. 프로그램에 Import 된 함수들을 탐색 할 수 있어야 한다. – IDA 의 rdata 섹션. 새로운 코드를 파일에 삽입해야 한다. 다행히도 실행파일(DLL)내에는 충분한 공간들이 존재. 컴파일러는 최적화를 통해서 함수 경계에 0x10바이트의 경계를 둠. 원하는 함수를 호출하기 위해선 GetProcAddress 함수가 필요. 이 함수가 import 되어 있지 않기 때문에 Import table 의 수정이 필요하다. Import table 의 수정. 컴파일러는 일반적으로 PE파일 내에 많은 여유공간을 만든다. – 결국 추가 코드 삽입이 어렵지 않음. 이를 위해 PE file Format 의 숙지 필요.

Crack10.exe - 계속 Import section 을 찾는다. Import section 의 구조. – 참고1, 참고2 이 section 의 첫번째 데이터는 IMAGE_IMPORT_DESCRIPTER 의 배열. 첫 두 바이트는 RVA 에 대한 포인터.(IMAGE_THUNK_DATA) .. 좀더 자세한 내용은 참고를 참고. 툴을 이용하면 쉽게 진행할 수 있지만, 이러한 과정을 손으로 해보자. 해커는 결국 그들의 머리와 손에 의존한다. 결국 이런 스킬 들이 필요하다. PEKPNXE by Kris Kaspersky. PE file format 의 학습. http://hdp.null2root.org/reversing/PE_analysis_anesra.pdf http://en.wikipedia.org/wiki/Portable_Executable

Limiting the Term of Use 많이 쓰이는 데모 버전 용 제한 기법 총 실행 횟수 제한. 정해진 기간 동안만 동작. 레지스트리나 외부 파일에 정보를 저장할 필요가 있다. 여러 가지 시도들. 레지스트리 수정. 시스템 시간 변경. 시간 시간의 수정.

Crack05.exe 처음 실행 후 20일 동안 유효하다. 재 설치는 전혀 도움이 되지 않는다. 첫 수행 시간은 어디에 기록 될까? 레지스트리? 이는 레지스트리 모니터 툴을 이용해서 쉽게 확인이 가능하다. Sysinternals 의 Regmon 사용. Vista 는 Process monitor 사용. 레지스트리를 수정 하는건 불편하다. Log 를 통한 Protection mechanism 의 분석. 먼저 HKEY_CURRENT_USER\SOFTWARE\CRACK05 라는 이름의 레지스트리 키를 찾는다. 만약 키가 존재 하지 않는다면 이 키를 생성하고 현재 시간을 세팅 한다. 키가 존재한다면, 현재 시간과 처음 실행된 시간을 비교해서 수행 여부를 결정한다.

Crack05.exe - 계속 프로그램이 항상 처음 수행된 효과가 나도록 코드를 수정한다. IDA 를 이용 RegCreateKeyExA 를 호출하는 곳을 찾는다. 리턴 값을 비교하는 곳을 찾아서 Jnz 명령을 nop 두개로 교체. LONG WINAPI RegCreateKeyEx( … ); Return Value If the function succeeds, the return value is ERROR_SUCCESS. If the function fails, the return value is a nonzero error code defined in Winerror.h. You can use the FormatMessage function with the FORMAT_MESSAGE_FROM_SYSTEM flag to get a generic description of the error. IDA-pro 를 이용한 disassemble 결과 그래프의 분기 관찰.

Crack06.exe 레지스트리가 아닌 파일에 저장 될 때 Filemon 을 사용 로그를 분석해서 어떤 파일을 사용하는지 파악 한다. Vista 의 경우 process monitor 앞 예제와 비슷한 코스로 Crack 시도.

Limiting the Number of Startups 앞 예에서와 마찬가지로 카운터를 저장할 필요가 있음. Filemon, regmon 의 로그를 통해서 Protection algorithm 분석 일반적인 응용프로그램은 수많은 레지스트리 키를 생성한다. 이중 어떤 것인 카운터 인가? 만능열쇠는 없다. 연속적 프로그램 실행의 결과 log 를 통해서 변경되는 부분을 발견할 수 있다.( 카운터가 증가 되거나)

Crack09.exe 카운터를 찾기가 힘들다. 변경되는 데이터가 어떤 때는 증가되고, 어떤 때는 감소 되는등 임의적이다. 진실을 밝히기 위해 debugger 와 disassembler 를 동원한다. IDA-pro 를 통한 분석. aCount1 의 이름을 찾고, xRef 로 참조 하는 곳으로 이동. Dec 부분을 nop 로 교체. RegQueryValueEx(hKey,"Count1",0,&TYPE,(LPBYTE) &Count1,&res); RegQueryValueEx(hKey,"Count2",0,&TYPE,(LPBYTE) &Count2,&res); Count2 = Count2 ^ Count1; Count2--; printf("Count %x \n",Count2); if (!Count2) return 0; srand((unsigned)time( NULL ) ); Count1 = (unsigned) rand(); RegSetValueEx(hKey,"Count1",0,REG_DWORD,(CONST BYTE *) &Count1,4); RegSetValueEx(hKey,"Count2",0,REG_DWORD,(CONST BYTE *) &Count2,4);

The Nag Screen 프로그램 중간 중간에 등록을 하란 메시지 박스로 귀찮게 함. 지속적인 귀찮음 유발로 정식 제품을 구매하도록 유도. 광고 등을 출력 하기도 한다. Nag screen 을 보고 참고 사용하거나, 정식 구매자가 되거나 사용자의 선택이다. 그러나 대부분의 사용자는 비용을 지불하기를 꺼린다. 이는 구매력이 없어서라기 보다는 정신적인 문제이다. Cracker 의 입장에선 이는 Protection mechanism 이 아니다. Nag screen 이 뜨지 않도록 코드를 수정하는 것은 어렵지 않다. 두 가지 일반적 방법. Key generator 의 사용. Nag screen 을 표시하는 코드의 수정. 후자는 권장하지 않는다. 전자가 쉽고 심플하다.

Crack0b.exe 프로그램 수행 중 주기적으로 표시되는 nag screen. 이때는 모든 기능 정지. 첫 번째 시도. dialog를 표시하는 부분의 코드를 수정. 어떻게 이 부분을 찾을 것인가? Dialog 를 생성하는 부분에 breakpoint 를 잡는 방법은 적절치 않다. MFC42.dll 내부에서 일어나는 일이라.. Cdialog::DoModal 을 시도하자. Domodal 의 ordinal 은 0x9d2 Breakpoint to mfc42!ORD 09D2 저자는 제대로 breakpoint 를 잡기 위해서 12시간 소모.

Crack0b.exe - 계속 Dialog::domodal 를 호출하는 코드를 수정 하는 건 무식한 방법. 위 함수를 호출하게 되는 조건을 처리하는 분기 문을 무력화 시킨다. 원하는 대로 동작한다. 끝인가? Cracker 들은 호기심이 많다. 당신이 진정한 cracker 이라면 내부 protection mechanism 이 어떻게 동작하고 있는지 관심을 가져야 한다.

Crack0b.exe - 계속 좀더 관찰 후 프로그램이 SetTimer 로 타이머를 생성후 매 타이머 이벤트 마다 다이얼로그를 생성한다. SetTimer 호출을 무력화 시킨다. 함수 호출 뿐만 아니라 스택 관련 코드도 같이 수정. 그냥 타이머의 시간을 아주 큰 수로 설정해서 통과를 시켜 보았다.

Crack0c.exe 시간과 상관없이 생성되는 nag screen. Spyxx 등으로 살펴봐도 WM_TIMER 메시지는 발생하지 않는다. 메시지 프로세싱 루프에서 현재 시간을 체크하거나, 독립된 쓰레드에서 전담해서 시간을 체크. 일반적으로 후자의 방법을 많이 사용. VC++ 의 process viewer 를 이용해서 관찰. 시간 체크 전용 쓰레드의 루프 코드를 무력화. HKEY_CURRENT_USER\Software\crack0c\Regit 의 생성으로 한방에

The Key File 가장 이상적인 방법. 두 가지의 접근 방법. 새로운 유효 키 파일의 생성. Protection mechanism 을 무력화 시키는 코드 수정. 일반적으로 첫 번째 방법 선호. 일반적으로 key 파일은 유져 이름과 등록 번호가 저장된다. 혹은 물리적으로 빠진 코드를 이 key 파일에 넣기도 한다. 이건 정말 쉽고도 크래킹을 현실적으로 불가능하게 만드는 방법이다. 여기서 불가능 하다는 말은 정식 제품을 구입하는 비용보다 크랙에 들어가는 비용이 더 크다는 의미 이다.

Crack11.exe File 의 존재 여부로 체크. Disassempler 로 확인. findFirstFileA를 호출하는 부분 발견. File monitor 로 확인. 단순히 파일의 존재 여부 뿐 아니라, 생성 시간, 파일 사이즈 등을 비교할 가능성 있음. FindFirstFile 함수는 해당 함수의 존재 여부 뿐만 아니라 _WIN32_FIND_DATA 의 정보도 리턴한다. typedef struct _WIN32_FIND_DATA { DWORD dwFileAttributes; FILETIME ftCreationTime; FILETIME ftLastAccessTime; FILETIME ftLastWriteTime; DWORD nFileSizeHigh; DWORD nFileSizeLow; DWORD dwReserved0; DWORD dwReserved1; TCHAR cFileName[MAX_PATH]; TCHAR cAlternateFileName[14]; } WIN32_FIND_DATA, *PWIN32_FIND_DATA, *LPWIN32_FIND_DATA;

Crack11.exe - 계속 실제 Protection mechanism 을 분석 전체 알고리즘을 무력화 시키는 부분은 아주 많은 assembly 언어대한 스킬이 필요. 쉬운 접근 방법 시도. IDA-Pro 의 disassemple 결과를 확인 하면 파일을 찾은 후 분기 하는 부분을 확인. 이 분기를 강제로 성공한 코드 영역으로 점프 하도록 코드를 수정.