工程代碼查看編譯器
⑴ 用什麼軟體來查看一個用Microsoft Visual C++ 6.0 編寫的程序的源代碼
標 題: MFC逆向初級研究（1）
作 者: 北斗之搖光
時 間: 2007-03-15 17:14
鏈 接: http://bbs.pediy.com/showthread.php?t=41087
詳細信息:
【文章標題】: MFC逆向初級研究(1)
【文章作者】: 北斗之搖光
【作者郵箱】: [email protected]
【下載地址】: 自己搜索下載
【作者聲明】: 只是感興趣，沒有其他目的。失誤之處敬請諸位大俠賜教!
--------------------------------------------------------------------------------
【詳細過程】
引言
本文主要針對微軟的VC++6.0中使用MFC產生的EXE文件的逆向研究，我曾經使用微軟的Visual Studio 2005編譯了一
個EXE文件，通過IDA反匯編以後發現該文件與VC++6.0產生的文件還是有所區別，因此特別在此聲明一下。文中主要使用了I
DA pro 5.0和在看雪(www.pediy.com)下載的OllyICE作為工具對目標文件進行反匯編。在此也感謝看雪論壇的各位的無私奉
獻，在研究過程的中的困難多通過各位的帖子得到了幫助。
逆向的關鍵
我認為逆向的關鍵主要是要弄明白目標文件的演算法和實現過程，在Window操作系統下，軟體的實現過程就體現在其
對Window消息的處理，而軟體的演算法則包含在處理的具體過程中。對於通過SDK編寫的"傳統"的Windows應用程序基本都具備
幾個共同的特徵：WinMain函數、WinProc函數、窗口注冊、消息循環。對於這類目標文件的分析主要集中的WinProc的分析上
，WinProc的函數地址獲得一般是通過窗口注冊函數中的參數獲得。（由於我對於這類文件沒有具體逆向過，所以只是大概的
說說，有不對的地方請各位不要客氣，盡管拍磚）
而使用MFC（Microsoft Function Class）顧名思義，該類庫主要封裝了大部分的Windows API函數所以在代碼中看
不到原本的SDK編程中的消息循環、窗口過程函數等等東西，所有這些封裝在相應的mfcxx.dll中，讓程序員能夠專著與處理
過程與演算法。這種做法於逆向而言有好處也有壞處：
壞處就是加大了對於MFC產生的EXE文件的逆向難度，讓許多的和我一樣的菜鳥迷失在匯編代碼中找不找北了，基本主要就靠
猜測實現過程中用到了那些函數，然後對文件導入表的函數下斷點來尋找我們所需要的處理過程；
好處就是這樣的做法使得EXE文件中主要都是目標程序的Window消息處理流程以及演算法，而且dll中的大部分函數的功能都能
在MSDN中查到。如果能夠通過對目標文件的分析得到這個Window消息處理流程和演算法架構，基本上我們就可以重寫整個軟體；
要做到上面的目標，首先我們要對MFC有所了解，推薦沒有基礎的兄弟們讀讀候俊傑的《深入淺出MFC》。該書在逆向過
程中完全可以作為一本參考書，讓你能通過源代碼了解實現過程，網上有很多該書的電子版下載。
一個逆向MFC產生的EXE文件的例子
下面我們就通過一個具體的例子來學習一下如何從目標文件中挖到我們需要的東西。首先我們來產生一個需要的EXE文件。
在此我假定各位對MFC有過一定的使用經驗，畢竟逆向分析才是本文的重點。
1．產生例子所需要的目標文件：
我們通過VC++6.0的向導來產生一個名為ReverseMFC的工程，這個工程的設置情況如下：
Application type of fff:
Dialog-Based Application targeting:
Win32
Classes to be created:
Application: CFffApp in ReverseMFC.h and ReverseMFC.cpp
Dialog: CFffDlg in ReverseMFCDlg.h and ReverseMFCDlg.cpp
Features:
+ Uses shared DLL implementation (MFC42.DLL)
+ Localizable text in:
中文[中國]
直接編譯以後就能夠運行，為了確定我們是否正確的分析的整個目標文件，在該對話框中加入一個我們自定義的按鈕如
下,對於該按鈕的處理函數如下設定為：
AfxMessageBox("I find it!",MB_OK)；編譯後就得到了我們需要的目標文件。
現在我們得到了所需要的目標文件，在IDA中載入該文件。在此我們最好是產生Release版本的EXE文件，畢竟所有的發
布軟體都是Release版本的。
2．具體分析
在IDA中按Ctrl＋S找到.rdata段，該段主要存儲了目標文件的類運行時創建信息、MessageMap信息、MessageEntry信息、
虛函數表、RTTI數據（如果編譯選項中選擇了支持RTTI的話）。
在到達.rdata段後我們可以看到這樣的代碼，對數據進行格式轉換後可以得到如下圖所示的數據。
.rdata:004021C0 ; 屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯?
.rdata:004021C0
.rdata:004021C0 ; Segment type: Pure data
.rdata:004021C0 ; Segment permissions: Read
.rdata:004021C0 _rdata segment para public 'DATA' use32
.rdata:004021C0 assume cs:_rdata
.rdata:004021C0 ;org 4021C0h
.rdata:004021C0 off_4021C0 dd offset sub_401000 ; DATA XREF: sub_401010o
.rdata:004021C4 dd offset dword_4021C8
.rdata:004021C8 dword_4021C8 dd 111h ; DATA XREF: .rdata:004021C4o
.rdata:004021CC dd 0
.rdata:004021D0 dd 0E146h
.rdata:004021D4 dd 0E146h
.rdata:004021D8 dd 0Ch
.rdata:004021DC dd offset CWinApp::OnHelp(void)
.rdata:004021E0 dd 0
.rdata:004021E4 dd 0
.rdata:004021E8 dd 0
.rdata:004021EC dd 0
.rdata:004021F0 dd 0
.rdata:004021F4 dd 0
.rdata:004021F8 off_4021F8 dd offset CWinApp::GetRuntimeClass(void)
.rdata:004021F8 ; DATA XREF: unknown_libname_1-56o
.rdata:004021FC dd offset sub_401040
.rdata:00402200 dd offset nullsub_2
.rdata:00402204 dd offset nullsub_3
.rdata:00402208 dd offset nullsub_2
.rdata:0040220C dd offset CCmdTarget::OnCmdMsg(uint,int,void *,AFX_CMDHANDLERINFO *)
其中的off_4021C0就是一個MessageMap數據；dword_4021C8就是MessageMap所指的MessageEntry數據；off_4021F8就是一個
類的虛函數表的開始位置。那麼具體這些數據時那個類的相關數據呢？如此判斷的依據是什麼？
首先我們知道MessageEntry是的數據結構定義如下，而且以6個0表示整個數組的結束。
struct AFX_MSGMAP_ENTRY
{
UINT nMessage; // windows message
UINT nCode; // control code or WM_NOTIFY code
UINT nID; // control ID (or 0 for windows messages)
UINT nLastID; // used for entries specifying a range of control id's
UINT nSig; // signature type (action) or pointer to message #
AFX_PMSG pfn; // routine to call (or special value)
};
因此我們有理由假設"dword_4021C8就是MessageMap所指的MessageEntry數據"。
而MessageMap數據結構定義如下：
struct AFX_MSGMAP
{
#ifdef _AFXDLL
const AFX_MSGMAP* (PASCAL* pfnGetBaseMap)();
#else
const AFX_MSGMAP* pBaseMap;
#endif
const AFX_MSGMAP_ENTRY* lpEntries;
};
off_4021C0的兩個數據中第二個數據恰恰就是我們前面假設為MessageEntry的指針，跟入其第一個數據，我們看到如下的代
碼：
.text:00401000 ; *************** S U B R O U T I N E ***************************************
.text:00401000
.text:00401000
.text:00401000 sub_401000 proc near ; DATA XREF: .rdata:off_4021C0o
.text:00401000 mov eax, ds:AFX_MSGMAP const CWinApp::messageMap
.text:00401005 retn
.text:00401005
.text:00401005 sub_401000 endp
恰恰是一個返回基類的MessageMap的函數。因此我們也同樣有理由假設"off_4021C0就是一個MessageMap數據"。
對於虛函數表的假設是如何被證明呢？首先我們要知道關於虛函數表的一點知識：虛函數表由虛函數的地址組成，表中函數
地址的順序和它們第一次出現的順序（即在類定義的順序）一致。若有重載的函數，則替換掉基類函數的地址。通過這個我
們可以知道MFC中虛函數表中的函數順序必然是先按照CObject->CCmdtarget->。。。。這個類繼承順序中的虛函數順序來處
理虛函數表中的函數順序的。只要證明這個我們"假設的虛函數"中的函數順序與上面提到的知識相符合則有理由說明我們的
假設成立。
首先來看CObject中虛函數的順序，在查看CObject的聲明文件後得到了這個類的虛函數順序：
virtual CRuntimeClass* GetRuntimeClass() const;
virtual ~CObject(); // virtual destructors are necessary
virtual void Serialize(CArchive& ar);
#if defined(_DEBUG) || defined(_AFXDLL)
// Diagnostic Support
virtual void AssertValid() const;
virtual void Dump(CDumpContext& dc) const;
再來查看CCmdtarget的虛函數順序，在查看CObject的聲明文件後得到了這個類的虛函數順序：
DECLARE_DYNAMIC(CCmdTarget)；
virtual BOOL OnCmdMsg(UINT nID, int nCode, void* pExtra,
AFX_CMDHANDLERINFO* pHandlerInfo);
#ifndef _AFX_NO_OLE_SUPPORT
// called when last OLE reference is released
virtual void OnFinalRelease();
#endif
#ifndef _AFX_NO_OLE_SUPPORT
// called before dispatching to an automation handler function
virtual BOOL IsInvokeAllowed(DISPID dispid);
virtual BOOL GetDispatchIID(IID* pIID);
virtual UINT GetTypeInfoCount();
virtual CTypeLibCache* GetTypeLibCache();
virtual HRESULT GetTypeLib(LCID lcid, LPTYPELIB* ppTypeLib);
之所以還要列出"DECLARE_DYNAMIC(CCmdTarget)；"是因為這個宏的定義如下：
#define DECLARE_DYNAMIC(class_name) \
protected: \
static CRuntimeClass* PASCAL _GetBaseClass(); \
public: \
static const AFX_DATA CRuntimeClass class##class_name; \
virtual CRuntimeClass* GetRuntimeClass() const; \
這個virtual CRuntimeClass* GetRuntimeClass() const; 覆蓋掉了一開始的CObject的相對應函數。依次按照類的順序對
照下來，就可以知道該表確實是虛函數表。同時，對應的GetMessageMap虛函數的位置上跟入後，可以得到如下代碼：
.text:00401010 ; *************** S U B R O U T I N E ***************************************
.text:00401010
.text:00401010
.text:00401010 sub_401010 proc near ; DATA XREF: .rdata:00402228o
.text:00401010 mov eax, offset off_4021C0
.text:00401015 retn
.text:00401015
.text:00401015 sub_401010 endp
恰恰是返回了我們之前假設的MessageMap的地址。
--------------------------------------------------------------------------------
【版權聲明】: 本文原創於看雪技術論壇, 轉載請註明作者並保持文章的完整, 謝謝!
⑵ 如何查看一個編譯器所含的庫函數
用編譯器提供的庫管理工具。
C語言的編譯器都會提供一個命令行工具，可以把自己編譯後的.obj模塊加入指定的庫文件，以後使用時只需要連接該庫文件即可。這個命令行工具通常是lib.exe，用這個工具可以查看庫中的模塊，可以把模塊加入到庫中，可以從庫中刪除模塊。這個工具不僅僅是自己建立的庫文件的管理工具，可以管理所有的庫文件，包括C語言提供的標准庫。
⑶ 下面段代碼是用哪個編譯器編譯的，我想看看運行結果！ #define AND && RE
如果有編譯器能編譯這個就神了。逗樂子的，別在意
⑷ codeblocks如何查看當前編譯器版本
Code::Blocks（codeblocks）是一個開源、免費、跨平台的c++ IDE。官方網站上稱其能滿足最苛刻的用戶的需求。雖有點誇張，但既然敢這樣說，也說明它的功能肯定不差。可擴展插件，有插件向導功能，讓你很方便的創建 自己的插件。Code::Blocks是用c++編寫的（用wxWidgets庫），捆綁了MinGW編譯器。
雖然Code::Blocks從一開始就追求跨平台目標，但是最初的開發重點是Windows平台，從06年3月21日版本:1.0 revision 2220開始，Code::Blocks在它的每日構建中正式提供GNU/Linux版本，這樣 Code::Blocks在1.0發布時就成為了跨越平台的C/C++IDE，支持Windows和GNU/Linux。由於它開放源碼的特點，Windows用戶可以不依賴於VS. NET，編寫跨平台C++應用。
Code::Blocks提供了許多工程模板，這包括:控制台應用、DirectX應用、動態連接庫、FLTK應用、GLFW應用、Irrlicht工程、OGRE應用、OpenGL應用、QT應用、SDCC應用、SDL應用、SmartWin應用、靜態庫、Win32 GUI應用、wxWidgets應用、wxSmith工程，另外它還支持用戶自定義工程模板。在wxWidgets應用中選擇UNICODE支持中文。
Code::Blocks支持語法彩色醒目顯示，支持代碼完成(目前正在重新設計過程中)支持工程管理、項目構建、調試。
Code::Blocks支持插件，包括代碼格式化工具AStyle;代碼分析器;類向導;代碼補全;代碼統計;編譯器選擇;復制字元串到剪貼板;調試器;文件擴展處理器;Dev-C++DevPak更新/安裝器;DragScroll，源碼導出器，幫助插件，鍵盤快捷鍵配置，插件向導;To-Do列表;wxSmith;;wxSmith MIME插件;wsSmith工程向導插件;Windows7外觀。
Code::Blocks具有靈活而強大的配置功能，除支持自身的工程文件、C/C++文件外，還支持AngelScript、批處理、CSS文件、D語言文件、Diff/Patch文件、Fortan77文件、GameMonkey腳本文件、Hitachi匯編文件、Lua文件、MASM匯編文件、Matlab文件、NSIS開源安裝程序文件、Ogre Compositor腳本文件、Ogre Material腳本文件、OpenGL Shading語言文件、Python文件、Windows資源文件、XBase文件、XML文件、nVidia cg文件。識別Dev-C++工程、MS VS 6.0-7.0工程文件，工作空間、解決方案文件。
Code::Blocks基於wxWidgets開發，正體現了wxWidgets的強大。以前Borland C++Builder X宣稱基於wxWidgets開發跨平台、兼容性好、最優秀的C++ IDE環境，但沒有實現;讓我們拭目以待。國內的Code::Blocks愛好者和跨平台開發員應該盡快建立中文Code::Blocks網站，提供Code::Blocks中文化支持，促進Code::Blocks在國內的發展。
⑸ 怎麼查看編譯器版本
你的是什麼編譯程序？
MYTC?
TC?
GCC?
GPP?
....
在VISUAL STUDIO命令提示里輸入
RC /?
第一行
Microsoft (R) Windows (R) Resource Compiler Version 5.2.3690.0
5.2.3690.0就是版本號了
⑹ 請問如何在myeclipse編譯器中查看java.class文件的源代碼為什麼我點擊這種文件都報 SOURCR NOT FOUND呢
在你eclipse中裝一個java反編譯器就能查看，.class文件的源代碼了
⑺ 如何在Code：Blocks下查看程序的匯編代碼
首先創建一個工程：Create a new project -> ConsoleApplication -> 填上工程文件名和project路徑 -> 調試器和編譯器默認。
隨便在工程里寫點什麼代碼，比如下面的一個遞歸代碼為例：
#include "stdio.h"
#include "math.h"
int factorial(int n);
int main(void)
{
int n, rs;
printf("請輸入斐波那契數n：");
scanf("%d",&n);
rs = factorial(n);
printf("%d \n", rs);
return 0;
}
// 遞歸
int factorial(int n)
{
if(n <= 2)
{
return 1;
}
else
{
return factorial(n-1) + factorial(n-2);
}
}
點擊「菜單欄 Debug -> Debugging windows -> disassembly」，把匯編窗口呼出來。
設定斷點。就是設置查看匯編的那一段代碼。在代碼的左邊（代碼行）右鍵就可以設定調試斷點了。
點擊調試，就可以看到匯編代碼了。如下：
如果想看指針或數組，可以編輯watch窗口，定義你想watch變數的類型。有很多窗口，自己可以多探索嘗試。
⑻ 如何查看IAR編譯器編譯後的匯編代碼，我想知道這個編譯器是如何處理中斷的
編輯界面右擊工程點擊options菜單項，選擇c/c++ compiler選項卡中的list選項，勾選output assembler files，編譯後則生成離線匯編代碼文件。
調試界面下，點擊view / disassembly 菜單項，則顯示在線匯編代碼窗口。
⑼ 如何在C語言中用宏來判斷當前編譯器
熱心網友
一.
#define是C語言中提供的宏定義命令，其主要目的是為程序員在編程時提供一定的方便，並能在一定程度上提高程序的運行效率，但學生在學習時往往不能理解該命令的本質，總是在此處產生一些困惑，在編程時誤用該命令，使得程序的運行與預期的目的不一致，或者在讀別人寫的程序時，把運行結果理解錯誤，這對 C語言的學習很不利。
1#define命令剖析
1.1 #define的概念
#define命令是C語言中的一個宏定義命令，它用來將一個標識符定義為一個字元串，該標識符被稱為宏名，被定義的字元串稱為替換文本。
該命令有兩種格式：一種是簡單的宏定義，另一種是帶參數的宏定義。
(1) 簡單的宏定義：
#define <宏名><字元串>
例： #define PI 3.1415926
(2) 帶參數的宏定義
#define <宏名> (<參數表>) <宏體>
例： #define A(x) x
一個標識符被宏定義後，該標識符便是一個宏名。這時，在程序中出現的是宏名，在該程序被編譯前，先將宏名用被定義的字元串替換，這稱為宏替換，替換後才進行編譯，宏替換是簡單的替換。
1.2 宏替換發生的時機
為了能夠真正理解#define的作用，讓我們來了解一下對C語言源程序的處理過程。當我們在一個集成的開發環境如Turbo C中將編寫好的源程序進行編譯時，實際經過了預處理、編譯、匯編和連接幾個過程，見圖1。