2010. 5. 18. 15:56

넷북을 쓰다 보면, 무선 연결이 불안정할 때가 많아 수시로 끊어진다. 그 자체는 문제가 아닌데, 그러다 보면 메신저들이 신나게 재접을 해대는 상황이 벌어지기 마련이다. 이 때 문제가 되는 것이, 네이트온의 경우 쓸데없는 광고가 뜬다는 것이다.

이 쓸데 없는 광고는 얼마나 쓸 데가 없냐면, 광고가 떠도 앞에 안 나오고 뒤에 숨어 있다가 네이트온 쪽지가 와서 보려고 쪽지창을 클릭할 때 광속의 속도로 전면으로 튀어나와서는 대신 클릭당한다. 그러면 Internet Explorer가-심지어 기본 브라우저를 딴 것으로 바꾸어두어도!-뜨면서 그게 완전히 뜨기까지 네이트온은 먹통이 되고, 그게 뜬 뒤에도 한동안 버벅거리는 것은 상당한 짜증을 동반시킨다.

그래서 나는 광고를 없애버리기로 다짐했다. 하는 김에 네이트온 접속 후의 스킨을 수정해서 광고를 떼보았다. 요놈도 상당히 자리를 차지해 넷북으로썬 상당히 귀찮다.

이것도 저것도 모르겠다, 하는 사람은 첨부된 파일을 받아다 적당히 풀면 되겠다. xml파일은 C:\Program Files\NATEON\Skins\DefSkin 에, exe파일은 C:\Program Files\NATEON\BIN에 넣으면 된다.

수정한 부분은 xml 파일에서는 아랫쪽에 주석처리된 부분 밑의 tr 태그를 죄다 지웠다. 그러고 나니까 별로 안예뻐서 miniview 들어가 있는 행과 그 아래 행은 살려뒀더니 원래부터 광고가 없었던 것 마냥 이뻐졌다ㅋ

exe파일에서는 '아마도' 광고 관련 처리하는 루틴을 전부 NOP으로 때워넣었는데, 위치가 0271d08부터 약 32byte 정도 된다. add esp, 24h 까지 덮으면 된다.

첨언: 찾아보니까 이미 한 사람이 많다...-_-;

'크래킹, 크랙미' 카테고리의 다른 글

AD free NateOn  (0) 2010.05.18
COM Object 생성 추적하기, COMTracer  (0) 2009.10.05
DLL injection with CreateRemoteThread()  (0) 2009.08.01
CBsearch Crack  (15) 2009.06.20
abexcrackme2  (0) 2007.02.17
2009. 10. 5. 13:25
JunkOn, DShower 프로젝트(?)를 추진 할 때, DirectShow 필터 생성을 추적할 필요가 있어서 제작해 보았던 툴이다.

디버거나 디버깅 스트링 뷰어 등을 연결해서 이 DLL을 인젝션시키면 대상 프로그램에서 생성되는 COM Object의 생성과 interface 요청을 추적하여 디버그스트링으로 COM Object의 사용을 추적할 수 있다.

핵심은 COM Object를 키로, 해당 Object가 소유한 QueryInterface를 값으로 쓰는 해시를 이용해 모든 QueryInterface를 감시하는 것이다. import table에 들어있을 리가 없기 때문에 후킹은 타겟 메소드의 처음 명령을 후킹하고자 하는 함수의 시작 주소로 점프하는 것으로 덮어쓰는 방법을 써서 후킹한다.





'크래킹, 크랙미' 카테고리의 다른 글

AD free NateOn  (0) 2010.05.18
COM Object 생성 추적하기, COMTracer  (0) 2009.10.05
DLL injection with CreateRemoteThread()  (0) 2009.08.01
CBsearch Crack  (15) 2009.06.20
abexcrackme2  (0) 2007.02.17
2009. 8. 1. 14:18
인터넷을 뒤지다가 같은 제목의 글이 맨 앞에 나오길래 패스했었는데, 읽어보니 내 쪽이 더 간단한거 같아서 글로 남길만한 가치가 있을 거 같아 다시 쓰기로 했다 -_-..

차례
  • 소개
  • 소스코드
  • 설명
  • 참고
소개

어떤 프로그램을 해킹하려 할 때는, 그 프로그램의 메모리에 접근하는 것이 필수적이다. 옛날 DOS와 같은 메모리 보호 기능이 없던 OS에서는 어렵지 않게 해당 프로그램의 메모리에 접근할 수 있었지만, 요즘과 같이 멀티태스킹과 메모리 보호가 기본인 상황에서는 그렇게 접근하는 것이 쉽지 않다. 그래서 자주 이용되는 방법이 디버거를 사용하는 방법이다.

하지만 이 디버거를 사용하는 경우에는 상당히 번거로운 것이 사실이다. 간단한 작업만 하면 되는데 그 커다란 디버거를 불러와야한다거나, 디버깅 API를 사용하려면 여러가지로 준비할 것이 많다거나, 해당 프로그램에서 디버거 디텍션 루틴을 넣어놨다면 또 복잡해지기도 해서 좀 더 간단한 방법을 사용할 수 있다면 쓰는 편이 낫다.

여기서 소개하려는 방법은 CreateRemoteThread()라는 API 함수를 통해 타겟 프로세스에 내가 만들어둔 DLL을 주입시키는 방법이다. DLL은 별도의 프로그램이지만, LoadLibrary 함수 등을 통해서 동적으로 링크되면 해당 프로세스의 주소 공간 내에 매핑되어 마치 처음부터 원래 프로그램과 같이 실행된 것 처럼 메모리 공간을 헤집을 수 있다는 특징이 있다. 매번 디버깅 API를 통해 메모리에 접근하는 것이 아니라, 이러한 부분을 DLL로 만들어서 주입함으로써 더 간단하게 타겟 프로세스를 주무를 수 있다.

소스코드
hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID);
if(hProc == NULL)
{
    MessageBox(hWnd, TEXT("Failed to inject DLL!\nCannot open the process"), NULL, MB_ICONERROR);
    break;
}
pRemoteDll = VirtualAllocEx(hProc, NULL, sizeof(char) * MAX_PATH, MEM_COMMIT, PAGE_READWRITE);
if(!pRemoteDll)
{
    CloseHandle(hProc);
    MessageBox(hWnd, TEXT("Failed to inject DLL!\nCannot allocate memory in target process"), NULL, MB_ICONERROR);
    break;
}
if(!WriteProcessMemory(hProc, pRemoteDll, szDllName, sizeof(szDllName), NULL))
{
    VirtualFreeEx(hProc, pRemoteDll, 0, MEM_RELEASE);
    CloseHandle(hProc);
    MessageBox(hWnd, TEXT("Failed to inject DLL!\nCannot write memory in target process"), NULL, MB_ICONERROR);
    break;
}
hKernel32 = LoadLibrary(TEXT("KERNEL32.DLL"));
pfnLoadLibrary = (LPTHREAD_START_ROUTINE)GetProcAddress(hKernel32, TEXT("LoadLibraryA"));

hThread = CreateRemoteThread(hProc, NULL, 0, pfnLoadLibrary, pRemoteDll, 0, NULL);
if(!hThread)
{
    VirtualFreeEx(hProc, pRemoteDll, 0, MEM_RELEASE);
    CloseHandle(hProc);
    FreeLibrary(hKernel32);
    MessageBox(hWnd, TEXT("Failed to inject DLL!\nCannot create remote thread"), NULL, MB_ICONERROR);
    break;
}
WaitForSingleObject(hThread, INFINITE);

VirtualFreeEx(hProc, pRemoteDll, 0, MEM_RELEASE);
CloseHandle(hProc);
FreeLibrary(hKernel32);
if(GetExitCodeThread(hThread, &dwRet))
{
    TCHAR out[1024];
    _stprintf(out, TEXT("Injection finished.\nExit code: 0x%08lX"), dwRet);
    MessageBox(hWnd, out, TEXT("Finished"), MB_ICONINFORMATION);
}
설명

여기서 사용한 핵심 API는 다음과 같다.
HANDLE WINAPI CreateRemoteThread(
__in HANDLE hProcess,
__in LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in SIZE_T dwStackSize,
__in LPTHREAD_START_ROUTINE lpStartAddress,
__in LPVOID lpParameter,
__in DWORD dwCreationFlags,
__out LPDWORD lpThreadId
);
LPVOID WINAPI VirtualAllocEx(
__in HANDLE hProcess,
__in_opt LPVOID lpAddress,
__in SIZE_T dwSize,
__in DWORD flAllocationType,
__in DWORD flProtect
);
CreateRemoteThread()는, 원래는 “다른 프로세스에 스레드를 생성할 때” 사용하는 함수다. 맨 앞에서 지정해주는 hProcess로 대상 프로세스를 지정해 줄 수 있다. 그런데 여기서, 스레드의 시작 주소를 지정해주는 lpStartAddress를 살펴보면 재밌는 사실을 하나 발견할 수 있다.

LPTHREAD_START_ROUTINE의 정의는 다음과 비슷하다.
DWORD WINAPI ThreadProc(
__in LPVOID lpParameter
);
그리고 DLL를 불러오는 함수인 LoadLibrary의 정의는 다음과 같다.
HMODULE WINAPI LoadLibrary(
__in LPCTSTR lpFileName
);
보다시피, 타입만 약간 다르고 실질적인 함수 호출에 있어서는 두 함수가 서로 똑같다는 것을 알 수 있다. 만약 타겟 프로세스 내의 LoadLibrary() 주소를 알 수 있다면 CreateRemoteThread()에 스레드 시작 주소로 LoadLibrary()를 넘겨주어 어렵지 않게 DLL을 주입할 수 있다는 것이 된다. 그리고 또 하나의 희소식은, Windows는 빠른 동적 링크를 위해서 각 DLL마다 선호하는 Base Address가 기록되어 있으며 충돌하지 않는 한 Base Address는 항상 고정되어 있다는 것이다. 따라서, 제일 먼저 로드되기 마련인 KERNEL32.DLL의 base address는 어떤 프로세스가 됐든 특별한 일 없이는 전부 똑같다는 말이 된다!

그러면 VirtualAllocEx()는 왜 필요할까? 바로 LoadLibrary()의 패러미터를 넘기기 위해 필요하다. LoadLibrary()는 고맙게도 시작 주소가 모든 프로세스마다 동일하지만 패러미터로 넘겨줄 DLL의 이름은 타겟 프로세스 내에서 찾아야 한다. 당연히, 이쪽의 주소를 넘겨주게 되면 해당 프로세스 내에서는 쓰레기 값이 참조되거나, 심지어는 잘못된 메모리 접근이 발생할 수도 있다. 그래서, 패러미터로 넘겨줄 DLL의 path를 넘기기 위해 VirtualAllocEx()로 타겟 프로세스 내에 메모리를 할당하고, 반환된 그 주소를 CreateRemoteThread()의 lpParameter로 넘겨주게 되면 LoadLibrary()의 스레드가 동작하면서 DLL을 주입시켜주게 되는 것이다. 주입과 동시에 실행되어야 할 코드들은 DLL 내의 DllMain() 함수 내에 집어넣으면 수행되게 된다. 구체적인 것은 MSDN의 DllMain() 항목을 참조하는 것이 좋을 것이다.

주의할 점은, 이 방법이 100% 동작하지 않을 수 있다.

참고

  • 해킹, 파괴의 광학 (와이미디어, 김성우 저) - 복잡한 방법밖에 실려있지 않지만, 상당한 참고가 될 것이다.
꽤 예전에 배워서 구현한 파일인데, 그러다보니 참조했던 곳이 다 사라져버렸다 -_-;;
여튼, 나중에 소개할지도 모르는 DirectShow 기반의 간단한 스트리밍 서비스 뚫기 등에서도 API 후킹에 많이 써먹었던 매우 유용한 툴이라, 많은 사람들이 유용하게 쓸 수 있으리라 믿는다.

'크래킹, 크랙미' 카테고리의 다른 글

AD free NateOn  (0) 2010.05.18
COM Object 생성 추적하기, COMTracer  (0) 2009.10.05
DLL injection with CreateRemoteThread()  (0) 2009.08.01
CBsearch Crack  (15) 2009.06.20
abexcrackme2  (0) 2007.02.17
2009. 6. 20. 18:44



급한 일이 생겨서 클럽박스 파일을 찾아야 하는데, 메이저한 사이트는 어느 하나도 제대로 된 링크를 제공해 주지 않기에 -_-... 구글에서 찾다 보니 CBsearch란걸 발견했다.

프리웨어라고 당차게 주장하길래 다운받아 주었더니, 이상한 사이트에 내 개인정보를 팔아야 쓸 수 있도록 한 애드웨어였다 -_- 게다가 개인정보 팔아봐야 인증 안되는거 같기도 하고...

그래서 짜증도 나고, 어차피 파일 하나만 받고 말텐데 하는 생각에 한번 크랙해보았다.

근데 이거 업데이트도 제대로 안됐는지 검색된 결과에 이미 사라진 박스도 많고 공식 사이트를 들어가봐도 제대로 관리되고 있는거 같지 않아서 일종의 VB 어플리케이션 크래킹 예제 정도의 가치가 있을 것 같다.

준비물
이 글에서는 OllyDbg v1.10, HxD를 이용했다.

어떻게 하나?

먼저, CBsearch를 실행시켜서 프로그램 인증->사이트 가입을 통한 인증을 선택해본다.
당연하지만, 인증하기를 누르면 반항한다. 그러면 이 메시지 박스가 호출되는 위치를 찾아내보자.

OllyDbg를 attach 기능을 통해 ClubboxSearch.exe(CBsearch)에 붙인다. 붙인 직후에는 브레이크포인트에 가 있기 때문에, 오른쪽 버튼을 눌러 컨택스트 메뉴를 띄운 후 View → Module 'ClubboxS' 를 선택해서 ClubboxSearch 본 프로그램으로 이동하자. 이동한 후에는 마찬가지로 컨택스트 메뉴를 띄우고 Search For → Intermodular calls를 선택해 ClubboxSearch.exe 프로그램 외의 함수를 호출하는 것들의 목록을 구해보자.
비베에서 MsgBox 함수를 호출할 때는 rtcMsgBox를 호출하니까, 키보드로 rtcMsgBox를 쳐서 이걸 찾는다. 찾았으면 Enter를 쳐서 호출하는 코드를 찾아 rtcMsgBox의 주소를 알아내자. rtcMsgBox의 주소를 알려면 호출하는 함수에서 다시 한번 Enter를 치면 호출되는 함수의 주소로 이동된다.

그 뒤에는 F2를 눌러 rtcMsgBox의 시작부분에 브레이크포인트를 걸고 F9를 눌러 프로그램을 계속 수행시킨다.

그리고 나서 다시 인증하기를 눌러보면, 아까 브레이크포인트를 건 곳에 딱 멈추는 것을 볼 수 있다.

이제, 이게 호출된 위치를 정확히 알아야 하니까 Ctrl+F9를 눌러 Execute till return, 즉 함수가 끝날 때까지 수행을 시킨다. 그러면 이 함수의 수행 결과는 뜬 메시지박스를 닫아야 뜨니까 생겨난 인증실패 창을 없애면 리턴 명령 위에 포인터가 위치해 있는 것을 볼 수 있다.

이제, 한 스텝만 F8로 수행시켜주자. 그러면 이 메시지박스를 호출한 위치를 알 수 있다.

근데 이 근처를 살펴보면, 적절한 코드가 잘 보이질 않는다. 하지만 이 함수가 인증절차를 수행하는 함수라는건 어렴풋이 짐작이 가능하니까, 일단 마찬가지로 Ctrl+F9를 또 눌러보자.

이상하게 이번엔 F8을 눌러도 바로 호출한 곳으로 이동하지 않지만, 당황하지 말고 F8을 몇 번 더 눌러주면 호출한 곳으로 이동한다.

흠... 비주얼 베이직 런타임이다. 그래도 여기서 호출한건 확실히 맞으니까, 호출하는 명령인 CALL EAX에다가 브레이크포인트를 걸어주자.

이제 다시 F9를 눌러준 뒤에, 인증하기 버튼을 다시 눌러보자. 그러면 방금 건 곳에 다시 멈추는 것을 볼 수 있다. 이때는 F8이 아닌 F7을 눌러서 함수 호출 안으로 들어갈 필요가 있다. 그리고 나서 한 칸씩 F8로 수행하면서 조건 점프를 찾아본다. (JNZ나 JE 같은 것들)

하다보면 이런 부분을 찾을 수 있다. 흠... 서울대 학생 or 졸업생 이시구나.

빙고, 조건 점프를 찾았다. 이렇게 하는 중에 가끔 exception이 발생해서 사람 짜증나게 하는데, 처음엔 Shift+F9를 눌러 넘어가주고 그 뒤에 다시 시도할 때는, 보통 함수 수행시 exception이 나기 때문에, CALL 다음에 브레이크포인트를 건 다음 F9로 넘어가는 시도를 하는게 괜찮다.

여기서 EAX를 보면 -1이다. 0이 아니면 점프하는데, 우리는 아직 인증을 받지 않았기 때문에 저거대로 따라가면 아마도 인증실패가 뜰거다. 그럼 저걸 어찌할까 하니, nop명령으로 바꿔 넘어가지 않도록 해보자. 바꾸려면 Space를 친 다음 nop이라고 치면 된다. 다시 올 때를 대비해 브레이크포인트를 걸고 F9로 계속 수행시켜보자.


ㅋ... 성공이다.

이제 검색해보자.
잘 된다ㅋ

자 이제, 이걸 영구히 저렇게 되게끔 만들어보자.

먼저 ClubboxSearch.exe의 시작 주소를 보면, 일반적인 win32 어플과 마찬가지로 00400000인 것을 쉽게 확인할 수 있다. 아까 nop으로 바꿨던 주소가 00577FAE 였으니까, 시작 주소를 뺀 00177FAE가 실제 파일에서의 offset이다.

실행중인 OllyDbg를 끄기 전에, 근처의 명령들의 기계어 코드를 어디에 메모해놓고 끈다. 왜냐하면, 저 주소가 진짜 nop으로 바꿔야할 명령의 주소인지 확인하기 위해서이다. 끄는 이유는 끄지 않으면 편집이 안된다.

85C0             TEST EAX,EAX
90 NOP ;여섯번
C745 FC 05000000 MOVE DWORD PTR SS:[EBP-4], 5

HxD를 열어 ClubboxSearch.exe를 열어보자. 그리고 Ctrl+G(이동)명령을 이용해서 00177FAE로 이동해보자.

위에 메모한 것과 같이 적혀 있는 곳을 발견했다. 아직 수정되기 전이라 JNZ가 그대로 있는 것을 볼 수 있다. 저 6 byte를 90으로 때우자.

그러면 이제 끝이다. CBsearch 지못미.

'크래킹, 크랙미' 카테고리의 다른 글

AD free NateOn  (0) 2010.05.18
COM Object 생성 추적하기, COMTracer  (0) 2009.10.05
DLL injection with CreateRemoteThread()  (0) 2009.08.01
CBsearch Crack  (15) 2009.06.20
abexcrackme2  (0) 2007.02.17
  • 지나가다 2009.07.14 10:41

    이 프로그램 크랙 좀 만들어 주시면 안될까요..
    하드 지워질때마다 인증해야하니 문제네요..

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2009.07.26 23:07

      제가 적어둔게 전부입니다;; 저거 따라 하시면 크랙 바로 만들어집니다.

  • 없는국번 2009.08.16 13:17

    이거 아직도 되나요? / 어태치 하니까 어태치가 안되는데 안티디버깅 된거 아닌가요? / 좀 갈켜 주세요

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2009.08.17 15:35

      어태치가 어떻게 안되는지 말씀해주셔야 알 거 같네요;; 적어도 제가 저 글을 쓰는 시점까지는 아무 문제가 없었거든요ㅎ 그리고 비베로 만든거 같던데 웬만큼 하지 않고는 비베로 안티디버거 달기는 좀;; 복잡하죠;

  • 2009.08.23 00:32

    점프하는 곳을 찾긴 찾았는데 님이 가르쳐준 모듈 부분이 아니고 Kernel32 모듈 부분에서 찾네요.. 이 곳이 맞긴 한 것 같은데.. 그럼 안티디버깅 된건가요?

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2009.08.23 23:37

      아 -_-;; 좀 스킬이 필요한 부분이 있군요.

      스샷을 확대해서 보시면 왼쪽에 주소가 있습니다. 그 주소로 가셔서 직접 수정하시면 됩니다.

      이 프로그램 절대 안티디버거 안달려 있을 겁니다 -_-

      그리고 kernel32쪽은 절대 아니니까 거긴 건드실 필요 없어요ㅎ 설명된 것은 대부분 비슷한 짓을 또 할 때 참고하라는 뜻으로 달아둔거니까요.

  • 2009.08.26 03:58

    네.. 동일한 번지로 가서 수정하니 되네요.. 단, 인증하기를 한번 더 눌러줘야 하는군요.. 저는 수정만 하면 인증하기 안 눌러도 되는줄 알았어요. 0F 85 5B 05 를 찾아도 되네요.. 두 개가 검색되는 것으로 봐서 두 개의 메시지 박스가 있네요(사이트가입과 이벤트 참여 겠죠?)

    그런데 왜 저는 F7로 쫓아가다보면 005로 시작하는 ClubBoxS 모듈의 번지는 안 보이고 7로 시작하는 kernel32와 MSVBVM60 모듈의 번지만 보일까요? 그리고 저는 attach 한 후부터 인증창 버튼을 누르기 위해 어플리케이션이 활성화되지 않아요.. F9를 눌러도. 클럽박스 검색창이 앞으로 안오네요. 정말 궁금해요... 제가 뭘 건너띈 것인지? 알려주실 수 없나요? 재밌는데..

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2009.08.28 15:11

      혹시 어태치 하신 뒤에 바로 F7 누르기 시작하셨나요? 어태치하면 브레이크포인트를 걸어서 자동으로 거기서 한번 멈추기 때문에 다시 실행을 시켜주셔야합니다; 단축키가 Ctrl+F9였나 했던거 같네요.

  • ㄷㄷㄷ ㅠ 2009.11.18 09:36

    혹시 '클럽서치' 라는 프로그램도 크랙하는 방법좀 알려주실 수 있나요????

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2009.11.18 23:06

      해 봤으면 알려드리겠지만...;;

      일단 저는 그게 뭐하는 프로그램인지도 모르겠군요;

  • ㄷㄷㄷ ㅠ 2009.11.20 19:42

    클럽서치도 클럽박스 검색 프로그램인데요,
    지금 CBSearch 프로그램 자체에 뭐가 이상이 생겼는지 폴더밖에 검색이 안되서요.... 파일모아라는 프로그램도 크랙을 해서 써봤지만, 서버 업데이트가 안됬는지 이미 존재하지 않는 박스에서 많이 찾더라고요;;;;
    클럽서치도 이제 담당하는 사람이 없어졌는데 이건 아마도 괜찮을거라고 생각해서....... 그런데 이건 어떻게 해야할지모르겠더군요///

  • 행인 2010.04.19 17:53

    뭐 지금도 답변해주실지는 모르겠지만 해주시면 감사하겠습니다.

    F9를 눌러서 찾고 멈추지 않고 게속 Runing 상태가 되는데 왜그런건가요?

    ---------------------------------------------------------
    그리고 나서 다시 인증하기를 눌러보면, 아까 브레이크포인트를 건 곳에 딱 멈추는 것을 볼 수 있다.
    ---------------------------------------------------------
    볼수가 없군요 -ㅅ-;;
    그 다음에 Excute till return 이 활성화 되지 않아요..
    화면 그대로 했는데 말입죠..


    답변 부탁드릴게요

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2010.04.19 22:34

      F9는 찾는 명령이 아니고 계속해서 수행시키는 명령입니다. 그 전에 rtcMsgBox에 F2로 브레이크포인트를 걸어 주셔야 합니다. 브레이크포인트를 안걸었거나, 틀린데 걸었으면 이런 일이 발생할 수 있죠 -_-;;

  • 왕초보 2010.05.01 03:13

    왕초보입니다. 완전기초도 안되있는...ㅠ

    이런쪽에 관심이 있어서 그런데요 이쪽 공부할려면 어떤걸

    공부해야되나요??

    • Favicon of http://blog.gwangyi.kr BlogIcon gwangyi 2010.05.03 13:11

      먼저 C언어와 WIN32 API에 대해서 어느 정도 파시고 어셈블리어를 배우면 조금 할 수 있게 됩니다.

      근데 제일 중요한건 끈기에요. 일주일 정도는 같은 문제 붙잡고 될때까지 매달릴 수 있어야 실력이 늡니다. 그 뒤에 따라오는게 어셈블리, 컴파일러의 특짐, C언어, API 이런거구요.

2007. 10. 19. 19:05
M 모 서비스와 J 모 서비스에서 테스트해보았다.

생각보다 DRM으로 보호되는 폐쇄적인 음원이라 해도 쉽게 풀린다는 것과 생각없이 만든다는 것을 배울 수 있었다.

그럴 생각이 있으신지 없으신지 모르겠지만 자체 포맷을 준비하지 않는 한 어쩔 수 없는 문제고, DShow 기술을 사용하는 한 더 쉽게 뚫릴 뿐이지.

아직 공개적으로 밝히긴 그렇고, 간단히 취약점에 대해 정리해 둔다.


'크래킹, 크랙미 > DRM' 카테고리의 다른 글

DRM Breaking  (0) 2007.10.19
2007. 2. 17. 02:21

abexcrackme2

크래킹, 크랙미 2007. 2. 17. 02:21


abexcrackme2

형태

실행시켜보면 알 수 있을 테지만, 이름을 넣고 시리얼을 넣은 뒤 체크를 하는 형태로 되어 있다.
디스어셈블러로 살펴보면 비베로 짜여져 있음을 알 수 있다.

접근

비교하는 함수인 MSVBVM60.__vbaVarTstNe 를 찾아본다.
이 때 매개변수로 넘어가는 값을 잘 살펴보면 원하는 키를 얻을 수 있다.
하지만 목표인 키젠을 만들기 위해서는 이 방법만으로는 부족하다.

위로 잘 훑어가다 보면, 이 비교를 수행하는 프로시저의 시작 부분을 찾을 수 있다.
일단, 자세히 보면 이름이 4글자 이상이어야 함은 쉽게 알 수 있다.
테스트를 위해 aaaa를 넣었을 때의 키를 알아보면 C5C5C5C5임을 알 수 있다.
두 번째로 abcd를 넣어보면, C5C6C7C8이 되는 것을 알 수 있다.
간단하게 추측해 보면, a의 아스키코드가 61이고, C5 - 61 = 64인 것으로 미루어보아 이 크랙미는 이름의 아스키코드에 64h를 더하여 시리얼을 구한다 라는 사실을 추론할 수 있다.

간단하게 키젠을 만들 수 있으나, VB는 유니코드를 사용하고 있으며 이는 한글과 같이 안시 코드페이지에서의 표현 방법과 유니코드상에서의 표현 방법이 다른 문자를 사용하게 되면 잘못된 결과를 도출한다는 문제점이 있다.
이를 해결하기 위해 살펴보면, 이 크랙미는 한 글자씩 떼어서 안시 코드 페이지로 바꾼 다음 64h를 더하여 16진수 형태로 시리얼을 출력한다는 것을 찾을 수 있다.
이를 이용하면 쉽게 키젠을 만들 수 있다.

키젠 소스 코드

keygen.c

(이 소스코드는 앞으로 몇번 더 쓰일 것이다)

p0.c


컴파일 명령(VC)


cl keygen.c p0.c /DUNICODE /DMAXNAME=5 /DMAXSERIAL=17 /Fekeygen.exe /link user32.lib gdi32.lib

(UNICODE 사용, MAXNAME 매크로를 5로 설정, MAXSERIAL 매크로를 17로 설정. user32.dll과 gdi32.dll의 API들을 사용한다.)

'크래킹, 크랙미' 카테고리의 다른 글

AD free NateOn  (0) 2010.05.18
COM Object 생성 추적하기, COMTracer  (0) 2009.10.05
DLL injection with CreateRemoteThread()  (0) 2009.08.01
CBsearch Crack  (15) 2009.06.20
abexcrackme2  (0) 2007.02.17