nezumi-lab
July 3rd, 2009, 14:18
in a nutshell: IDA-Pro 5.5.0.925 has been updated on July-01/2009 in order to fix a bug in BOCHSDBG plug-in. from now on it supports unaligned PE files (see definition below). if you want to get the updated version, send your identification (the ida.key) to support@hex-rays.com ("support@hex-rays.com").
nude statement: I don’t like IDA-Pro Debugger. it’s very limited, devilish uncomfortable and embarrassing. it has its own benefits, none the less, but for me OllyDbg is much better. every man has his taste - opinions differ.
death notice: OllyDbg/Soft-Ice (like any other x86 debugger) is very limited. it could be detected, it could be broken. it does not support tracing of a self-traced program and there is no workaround — no script nor plug-in to fix it. it’s nature of x86 CPU. the same story with DRx registers. virtualization and emulation is the only way to hack strong protections (oh, come on! as if you can’t break an emulator, whose behavior is pretty different from native CPU).
brutal facts: what do we have?! is there any decent emulator?! well, x86emu (plug-in for IDA-Pro) is extremely limited. BOCHSDBG is good enough to debug MBR or OS loader, but… how we’re supposed to debug applications/drivers, working _below_ the Operation System?! the same story with VMWare/WinDbg and QEMU/GDB. so, in essence there is no decent emulators, except for internal products like McAfee EDebug (very good tool, but only for home consumption, “home” means “McAfee”
.
beam of hope: IDA-Pro debugger had been significantly improved since 5.4 and the most dramatically change is BOCHSDBG plug-in supporting win32 PE debugging. what does it mean and how it works? well, to answer the first question: we got what we were waiting for a looong time. yeah, there was BOCHS, but it’s impossible to debug code snippets directly into BOCHS. the only way to do it - create an image of a tiny operation system and put a snippet there. CPU starts in real 16 bits mode, while win32 programs expect to see 32-bit protected mode with flat address space - the minimum requirements to debug code snippets, but it’s not enough to hack real applications!
the next step is to create win32-like environment. at least we need to emulate fundamental system structures (like PEB) and engines (SEH for example) not mention basic API set. it’s been hell of a job ("http://www.google.es/bsd") (or, may be, a job in hell). and this job has been done by Elias Bachaalany, he is our hell-guy - very talented brick from the eastern shore of the Mediterranean Sea. not wonder that he is a clever cat!
a mint of intrigue: it was excitement from the first sight when I read Ilfak’ post “Bochs Emulator and IDA? ("http://hexblog.com/2008/10/bochs_emulator_and_ida.html")“. it was just awesome! at that moment my company provided me a license for IDA-Pro 5.3, but it was too old to be updated for a free, so I kicked up my heels. McAfee provided me a license as well (Danke schön to the director of IPS research of Avert Labs ("http://www.avertlabs.com/research/blog/"), it was very kind of him and maybe I will find myself in his team based in Santa-Clara ("http://maps.google.com/maps?source=ig&hl=en&channel=2PSP&ie=UTF8&q=mcafee+santa+clara&fb=1&split=1&cid=0,0,4736335298098330 813&ei=U1VOSpuOMomE-QacqsSFBA&t=h&z=16")). but… it was IDA-Pro 5.3 - the original CD, shipped to Moscow McAfee office, hosted in the biggest building in Europe - Naberezhnaya Towers ("http://en.wikipedia.org/wiki/Naberezhnaya_Tower"), but I was unable to get the updates because of security polices of McAfee. I had no access no the internal network and sardonic Firewall did not allow to go outside. what’s a piggishly! only when IDA-Pro 5.5 has been released, I got the updates directly from hex-rays.com, sitting in Macrovision office ("http://nezumi-lab.org/blog/?p=168") and thinking that even in my village Internet is faster (I own 10 Mbytes link, but an average speed is 2 Mbytes, but it’s more that enough to fit my needs).
collapse of plans: I started testing the new plug-in, trying to debug programs (malware mostly) that I was unable to debug with OllyDbg and the old IDA-Pro debugger. the first impression was: wow! it’s cool! it’s easy to trace self-tracing code, “software” breakpoints are not changed the content… well, I felt like I reached the golden gates (or it was Golden Bridge ("http://nezumi-lab.org/gif/sfo_gb_l1_small.jpg")?) and was about to dine with Mohammed, happy hunting ground - Elias made the best of both worlds, but… better to reign in hell than serve in heaven. BOCHSDBG plug-in is a great tools, yet it’s all wrong. the whole design is wrong. it’s easy to break the debugger.
for example: it traces programs by BOCHS virtual CPU engine. the very engine is used by the debugged program, so… no problem to detect the debugger, yet it’s harder than beat a non-virtual one. (now I’m working on anti-debugging tricks some of them will be posted here, some - for commercial purposes).
the facts: when you choose Loader Type -> PE in BOCHS configuration message box, the plug-in prepares a virtual image and loads PE file there. so, we should expect a lot of problem, because it’s almost impossible to design a decent 3rd party PE Loader. the problem is: MS PE Specification is not accurate and MS does not follow it. take Section Alignment for example. according to MS PE specification, the minimal Section Alignment == PAGE_SIZE, but win/32 supports much smaller values as well (win/64 does not) and the smallest alignment, supported by standard MS Linker, is 10h. lets come to terms to call these files “unaligned PE” - it’s not a good term, because the files are still aligned, yet the align value is much smaller than the specification requires, but it’s just a term :-)
IDA-Pro 5.5.0.95 BOCHSDBG Plug-in does not support unaligned PE files, and generates an exception on any writing attempt, even if the section is writable (in fact, even the section is not writable, the system PE loader makes _all_ sections writable, regardless of the attributes - but I will keep this feature to another post). just a few people have a chance to meet an unaligned PE, because these files are not common for commercial applications, but malware use this trick quite often in order to be smaller, and I met the problem on the second day of using IDA-Pro BOCHSDBG Plug-in.
in the can: to demonstrate the problem I created a very simple file. download ("http://nezumi-lab.org/ffh/ida-bug_bochsdbg-16.zip") it or see the source below:
as you can see, unaligned exe works fine, OllyDbg and local IDA-Pro debugger have no problem with it, but… go to Debugger menu, click “Switch Debugger”, select “Local Bochs debugger” and run it by F9 or try to trace step-by-step.
ops!!! an exception on a write attempt (see the pic below), accessing “mem” variable, which belongs to .data section, which is writable. remove “/ALIGN:16” key from the linker arguments, rebuild the program and try to debug it again. now it works fine! but… we can’t rebuild closed source program!!! so, it’s a problem and now it’s fixed. just ask the support for the updated version.
http://nezumi-lab.org/gif/ida-bug_bochsdbg-16.pngIDA-Pro 5.5.0.925, BOCHSDBG, unaligned pe, impact area
http://nezumi-lab.org/blog/?p=178
nude statement: I don’t like IDA-Pro Debugger. it’s very limited, devilish uncomfortable and embarrassing. it has its own benefits, none the less, but for me OllyDbg is much better. every man has his taste - opinions differ.
death notice: OllyDbg/Soft-Ice (like any other x86 debugger) is very limited. it could be detected, it could be broken. it does not support tracing of a self-traced program and there is no workaround — no script nor plug-in to fix it. it’s nature of x86 CPU. the same story with DRx registers. virtualization and emulation is the only way to hack strong protections (oh, come on! as if you can’t break an emulator, whose behavior is pretty different from native CPU).
brutal facts: what do we have?! is there any decent emulator?! well, x86emu (plug-in for IDA-Pro) is extremely limited. BOCHSDBG is good enough to debug MBR or OS loader, but… how we’re supposed to debug applications/drivers, working _below_ the Operation System?! the same story with VMWare/WinDbg and QEMU/GDB. so, in essence there is no decent emulators, except for internal products like McAfee EDebug (very good tool, but only for home consumption, “home” means “McAfee”
.beam of hope: IDA-Pro debugger had been significantly improved since 5.4 and the most dramatically change is BOCHSDBG plug-in supporting win32 PE debugging. what does it mean and how it works? well, to answer the first question: we got what we were waiting for a looong time. yeah, there was BOCHS, but it’s impossible to debug code snippets directly into BOCHS. the only way to do it - create an image of a tiny operation system and put a snippet there. CPU starts in real 16 bits mode, while win32 programs expect to see 32-bit protected mode with flat address space - the minimum requirements to debug code snippets, but it’s not enough to hack real applications!
the next step is to create win32-like environment. at least we need to emulate fundamental system structures (like PEB) and engines (SEH for example) not mention basic API set. it’s been hell of a job ("http://www.google.es/bsd") (or, may be, a job in hell). and this job has been done by Elias Bachaalany, he is our hell-guy - very talented brick from the eastern shore of the Mediterranean Sea. not wonder that he is a clever cat!
a mint of intrigue: it was excitement from the first sight when I read Ilfak’ post “Bochs Emulator and IDA? ("http://hexblog.com/2008/10/bochs_emulator_and_ida.html")“. it was just awesome! at that moment my company provided me a license for IDA-Pro 5.3, but it was too old to be updated for a free, so I kicked up my heels. McAfee provided me a license as well (Danke schön to the director of IPS research of Avert Labs ("http://www.avertlabs.com/research/blog/"), it was very kind of him and maybe I will find myself in his team based in Santa-Clara ("http://maps.google.com/maps?source=ig&hl=en&channel=2PSP&ie=UTF8&q=mcafee+santa+clara&fb=1&split=1&cid=0,0,4736335298098330 813&ei=U1VOSpuOMomE-QacqsSFBA&t=h&z=16")). but… it was IDA-Pro 5.3 - the original CD, shipped to Moscow McAfee office, hosted in the biggest building in Europe - Naberezhnaya Towers ("http://en.wikipedia.org/wiki/Naberezhnaya_Tower"), but I was unable to get the updates because of security polices of McAfee. I had no access no the internal network and sardonic Firewall did not allow to go outside. what’s a piggishly! only when IDA-Pro 5.5 has been released, I got the updates directly from hex-rays.com, sitting in Macrovision office ("http://nezumi-lab.org/blog/?p=168") and thinking that even in my village Internet is faster (I own 10 Mbytes link, but an average speed is 2 Mbytes, but it’s more that enough to fit my needs).
collapse of plans: I started testing the new plug-in, trying to debug programs (malware mostly) that I was unable to debug with OllyDbg and the old IDA-Pro debugger. the first impression was: wow! it’s cool! it’s easy to trace self-tracing code, “software” breakpoints are not changed the content… well, I felt like I reached the golden gates (or it was Golden Bridge ("http://nezumi-lab.org/gif/sfo_gb_l1_small.jpg")?) and was about to dine with Mohammed, happy hunting ground - Elias made the best of both worlds, but… better to reign in hell than serve in heaven. BOCHSDBG plug-in is a great tools, yet it’s all wrong. the whole design is wrong. it’s easy to break the debugger.
for example: it traces programs by BOCHS virtual CPU engine. the very engine is used by the debugged program, so… no problem to detect the debugger, yet it’s harder than beat a non-virtual one. (now I’m working on anti-debugging tricks some of them will be posted here, some - for commercial purposes).
the facts: when you choose Loader Type -> PE in BOCHS configuration message box, the plug-in prepares a virtual image and loads PE file there. so, we should expect a lot of problem, because it’s almost impossible to design a decent 3rd party PE Loader. the problem is: MS PE Specification is not accurate and MS does not follow it. take Section Alignment for example. according to MS PE specification, the minimal Section Alignment == PAGE_SIZE, but win/32 supports much smaller values as well (win/64 does not) and the smallest alignment, supported by standard MS Linker, is 10h. lets come to terms to call these files “unaligned PE” - it’s not a good term, because the files are still aligned, yet the align value is much smaller than the specification requires, but it’s just a term :-)
IDA-Pro 5.5.0.95 BOCHSDBG Plug-in does not support unaligned PE files, and generates an exception on any writing attempt, even if the section is writable (in fact, even the section is not writable, the system PE loader makes _all_ sections writable, regardless of the attributes - but I will keep this feature to another post). just a few people have a chance to meet an unaligned PE, because these files are not common for commercial applications, but malware use this trick quite often in order to be smaller, and I met the problem on the second day of using IDA-Pro BOCHSDBG Plug-in.
in the can: to demonstrate the problem I created a very simple file. download ("http://nezumi-lab.org/ffh/ida-bug_bochsdbg-16.zip") it or see the source below:
int mem; char *txt=”[OK]“;to make it, run “nmake make” or use the following command lines:
__declspec(naked) nezumi()
{
__asm{ mov [mem], eax }
MessageBox(0, txt, txt, 0); ExitProcess(0);
}
$cl.exe /c /Ox ida-bug_bochsdbg-16.cignore the linker warning “LiLNK4108: /ALIGN specified without /DRIVER or /VXD; image may not run” — image works fine on 32-bits editions of NT, W2K, XP, S2K3/S2K8, Vista (64-bits editions probably will not run it, but I have not checked it by myself, if you have 64-bits editions of Windows under your hand, please test it and post your comment here, thanks!)
$ink.exe ida-bug_bochsdbg-16.obj /ALIGN:16 /ENTRY:nezumi /SUBSYSTEM:WINDOWS KERNEL32.lib USER32.lib
as you can see, unaligned exe works fine, OllyDbg and local IDA-Pro debugger have no problem with it, but… go to Debugger menu, click “Switch Debugger”, select “Local Bochs debugger” and run it by F9 or try to trace step-by-step.
ops!!! an exception on a write attempt (see the pic below), accessing “mem” variable, which belongs to .data section, which is writable. remove “/ALIGN:16” key from the linker arguments, rebuild the program and try to debug it again. now it works fine! but… we can’t rebuild closed source program!!! so, it’s a problem and now it’s fixed. just ask the support for the updated version.
http://nezumi-lab.org/gif/ida-bug_bochsdbg-16.pngIDA-Pro 5.5.0.925, BOCHSDBG, unaligned pe, impact area
http://nezumi-lab.org/blog/?p=178