Дизассемблирование MFC-приложений

Я уже давно любитель покопаться в чужих прогах, но постоянно спотыкаюсь на тех из них, которые написаны с помощью MFC. Помогите пожалуйста разобраться, как лучше исследовать MFC-программы.
Собственно вот:

Код (Text):

1. .text:0041B5D6 ; int __stdcall wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nShowCmd)
2. .text:0041B5D6 _wWinMain@16    proc near               ; CODE XREF: ___tmainCRTStartup+14Bp
3. .text:0041B5D6
4. .text:0041B5D6 var_18          = dword ptr -18h
5. .text:0041B5D6 var_10          = dword ptr -10h
6. .text:0041B5D6 var_8           = dword ptr -8
7. .text:0041B5D6 var_4           = dword ptr -4
8. .text:0041B5D6 hInstance       = dword ptr  8
9. .text:0041B5D6 hPrevInstance   = dword ptr  0Ch
10. .text:0041B5D6 lpCmdLine       = dword ptr  10h
11. .text:0041B5D6 nShowCmd        = dword ptr  14h
12. .text:0041B5D6
13. .text:0041B5D6                 mov     edi, edi
14. .text:0041B5D8                 push    ebp
15. .text:0041B5D9                 mov     ebp, esp
16. .text:0041B5DB                 pop     ebp
17. .text:0041B5DC                 jmp     loc_41B72C
18. .text:0041B5E1 ; ---------------------------------------------------------------------------
19.  
20. .............................................................................................................................................
21.  
22. .text:0041B72C loc_41B72C:                             ; CODE XREF: wWinMain(x,x,x,x)+6j
23. .text:0041B72C                 jmp     ds:mfc90u_1272
24. .text:0041B72C _wWinMain@16    endp ; sp-analysis failed
25. .text:0041B72C
26. .text:0041B72C ; ---------------------------------------------------------------------------

Тут явно видно, что истинная точка входа - не WinMain, тогда как её найти?
Ну и в кратце просветите про структуру MFC-программ, дайте полезных ссылочек, где можно почерпнуть нужную информацию быстро.
Спасибо.

 

В гугле "Reversing MFC Applications" вторая ссылка.

 

Artem_N
Вторая ссылка:


А вообще я удивлён, - на запрос "дизассемблирование MFC-программ" гугл выдаёт воду про дизассемблирование в целом. Что, не ужели в России MFC-приложения не хакают? Или отечественное движение реверсеров вырождается? Судя по активности участников WASM.RESEARCH, это похоже на правду

Всё равно продолжаю поиски, ну и естественно надеюсь на Вашу помощь. Не верю, что ссылка, данная Artem_N'ом (и которая привела хз куда), единственная.

 

LShadow77
Отключите антивирус, скачайте, там скрипт для олли и сэмпл, который и определяется как Malware, на самом деле является обычным crackme.

 

Как я погляжу, вы в камасутре преуспели гораздо больше, чем в реверсинге. Я рад за вас!
Что касается меня, то я не претендую на звание гения дизассемблирования и создал эту тему в расчёте на реальную помощь, а не поток флуда.

Вот, пока что набрёл на эту статью: http://www.woodmann.com/forum/entry.php?134-Guidelines-to-MFC-reversing, уже хоть что-то...

 

LShadow77
Подумаешь, какое-то ложное срабатывание. PDF-файла в том архиве хватит для входа в тему

MFC сложная штука, чтобы вот так вот сразу.

 

Так какие проблемы? Напишите собственное простейшее MFC-приложение (в Интернете можно найти прогу размером менее 20 строчек), скомпилируйте его в отладочном режиме и начинайте исследовать структуру вашего бинарника (с отладочными символами). А вообще-то, как по мне, то это и не особенно нужно, если, конечно, вас не интересует собственно системный MFC-менеджер. Достаточно понимать, что WinMain просто передает управление MFC-менеджеру, а тот уже рано или поздно вызовет все ваши подпрограммы и функции. А во всем остальном вы будете иметь дело с «сишным» ассемблером.

P.S. Кстати, вот нашел у себя простейшую MFC-прогу:

Код (Text):

1. #include <afxwin.h>
2.  
3. #define IDR_MAINFRAME                   128
4.  
5. class CMainApp : public CWinApp {
6.     public: virtual BOOL InitInstance() {
7. //*** Первый вариант
8. //*
9.         //CFrameWnd *pFrameWnd = new CFrameWnd;
10.  
11.         //pFrameWnd->Create(NULL, _T("Дикий век, грубые нравы, романтизма нет!"));
12.  
13.         //m_pMainWnd = pFrameWnd;
14.         //m_nCmdShow = SW_MAXIMIZE;    
15.        
16.         //m_pMainWnd->ShowWindow(m_nCmdShow);
17.  
18.         //return TRUE;
19. //*
20. //*** Первый вариант
21.  
22. //*** Второй вариант
23. //*
24.         CFrameWnd *pFrameWnd = new CFrameWnd;
25.  
26.         pFrameWnd->Create(NULL, _T("Мелодия для флейты без фортепиано"));
27.  
28.         m_pMainWnd = pFrameWnd;
29.  
30.         int cx = ::GetSystemMetrics(SM_CXSCREEN)/12;
31.         int cy = ::GetSystemMetrics(SM_CYSCREEN)/8;
32.        
33.         m_pMainWnd->SetWindowPos(NULL, cx, cy, 10*cx, 6*cy, SWP_NOZORDER | SWP_SHOWWINDOW);
34.  
35.         return TRUE;
36. //*
37. //*** Второй вариант
38.     };
39. };
40.  
41. CMainApp theApp;

 

Вот же ж пипец! Уже 5-й час качаю MS Visual Studio 2008, и всё только для того, чтобы получить исходники MFC90 и def-файл, без которого не получится связать ординалы с символьными именами


Про дзен реверса можете мне не рассказывать. В своё время просиживал в дизассемблере по 16 часов в сутки, забывая пожрать. Модифицировал множество игр, расшифровал несколько форматов PACK-файлов, копался в прогах, чтобы понять "как это сделано". Это к тому, что кое-какой опыт дизассемблирования у меня всё же имеется.
MFC это не C++, - это навороченная объектноориентированная надстройка над Win32 API. А C++ - это язык программирования и знаю я его на достаточном уровне, уж поверте.
Вот конкретно в MFC - плаваю, потому и создал эту тему.

 

Прочитайте статью «Создание универсальных def и lib-файлов для «чужих» dll», уверен, что тогда уже можно будет не качать 5 часов MS Visual Studio 2008 .