Practical C++ Decompilation | Recon 2011 | Igor Skochinsky
Why Reverse Engineering Stack Exchange recommends it
Reverse Engineering Stack Exchange answerers and askers point to it as the go-to walkthrough for analyzing C++ binaries, especially vtables, class layouts and constructors.
Recommended by 1 people across 1 different months, 2013 to 2018.
What it is
A 56-minute conference talk from Recon 2011 in which Igor Skochinsky, author of IDA Pro tooling and a long-time reverse engineer, explains how to recover C++ structure from compiled binaries. He covers representing classes as structures, vtables as structures of function pointers, and handling inheritance and multiple vtables.
What people said
Recommends Igor Skochinsky · 2013-03 · Reverse Engineering Stack Exchange · on “Static analysis of C++ binaries”
I gave a talk at Recon in 2011 ("Practical C++ Decompilation") on this exact topic. Slides [LINK] and video [this video] ( mirror [this video] ) are available. The basic approach is simple: represent classes as structures, and vtables as structures of function pointers. There are some tricks I described that allow you to handle inheritance and different vtables for the classes in the same hierarchy. These tricks were also described on this blog [LINK] ; I'm not sure if it was based on my talk or an independent work. One additional thing that I do is add a repeatable comment to each slot in the vtable structure with the implementation's address. This allows you to quickly jump to the implementation whe
Cites Ci3 · 2017-07 · Reverse Engineering Stack Exchange · on “What are these extra members in this derived constructor?”
In Recon 2011: Practical C++ Decompilation [this video] there is this example where some fields are assigned before the derived class' virtual table pointer is: public: __thiscall CMachine::CMachine(void) proc near mov edi, edi push esi mov esi, ecx call CDataStoreObject::CDataStoreObject(void) and dword ptr [esi+24h], 0 or dword ptr [esi+28h], 0FFFFFFFFh and dword ptr [esi+2Ch], 0 or dword ptr [esi+30h], 0FFFFFFFFh mov dword ptr [esi], offset const CMachine::`vftable' mov eax, esi pop esi retn public: __thiscall CMachine::CMachine(void) endp Igor mentions that the assigning of those fields are not written by the programmer because they come before the virtual table pointer. Would someone mind ex
Cites Biswapriyo · 2018-11 · Reverse Engineering Stack Exchange · on “Get interface definition of undocumented COM objects”
This is just an extension of @0xC0000022L's answer. For this question, I will explain ICMLuaUtil COM interface below because IFileOperation COM interface is in shell32.dll , too big ;) You mentioned the wrong CLSID. Here I provide a list of them: GUID CLSID_CmstpLua = {3E5FC7F9-9A51-4367-9063-A120244FBEC7} GUID IID_ICmstpLua = {6EF07F29-F9B8-4DA4-B59E-13DEA060AD60} GUID IID_ICmstpLua2 = {AE8AFD54-5B57-4961-8A9B-12ADF23B696A} GUID CLSID_CMLuaUtil = {3E000D72-A845-4CD9-BD83-80C07C3B881F} GUID IID_ICMLuaUtil = {6EDD6D74-C007-4E75-B76A-E5740995E24C} How to find the DLL file path from CLSID [LINK] without using any 3rd party program? Open this registry path HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLS