# IDA-Pro 5.5 has been updated, fixed — Bochs plug-in unaligned PE bug

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.

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 dramatical 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 has been hell of a job (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?“. 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, it was very kind of him and maybe I will find myself in his team based in Santa-Clara). but… it was IDA-Pro 5.3 – the original CD, shipped to Moscow McAfee office, hosted in the biggest building in Europe – Naberezhnaya Towers, but I was unable to get the updates because of security policies of McAfee. I had no access to the internal network and the 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 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 do not changed the content… well, I felt like I reached the golden gates (or it was Golden Bridge?) 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 tool, 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 problems, 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 it or see the source below:

int mem; char *txt=”[OK]“;
__declspec(naked) nezumi()
{
__asm{ mov [mem], eax }
MessageBox(0, txt, txt, 0); ExitProcess(0);
}

to make it, run “nmake make” or use the following command lines:

$cl.exe /c /Ox ida-bug_bochsdbg-16.c
$Link.exe ida-bug_bochsdbg-16.obj /ALIGN:16 /ENTRY:nezumi /SUBSYSTEM:WINDOWS KERNEL32.lib USER32.lib

ignore 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!)

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.

updated on: Sun, July 05, 04:44: grammar fix

IDA-Pro 5.5.0.925, BOCHSDBG, unaligned pe, impact area

IDA-Pro 5.5.0.925, BOCHSDBG, unaligned pe, impact area

Tags: , ,  

6 Comments

  1. The file won’t load in Vista64. I haven’t managed to get small alignments to work on Vista64.
    Regarding the “all sections become writable”, that’s not quite correct, but I’ll wait for your post before we get into details. ;-)

  2. thanks for info. wrt “all sections become writable”, plz see http://nezumi-lab.org/ffh/all_writable.zip

  3. We thought file will load on vista64 when number of sections would be set to zero (“sections” with such small alignment are kinda bogus anyway). That didn’t work – result was the same (“The application failed to initialize properly bla-bla-bla 0xC0000018″). But intresting thing – when we set number of section to null _and_ wiped out the header of the first section with zeroes, file loaded and worked fine (that’s right, on vista64). Although, we guess, scenario with no sections at all was probably correctly handled even with the previous version of bochsdbg plugin.

    Also, regarding ‘all writable’ – we wonder if the latest IDA+Bochs can be detected using IAT-size trick. (As everyone knows, before fixing imports, loader VirtualProtect’s IAT (according to DataDirectory[IAT]) to be writable, and when imports are fixed, sets IAT’s protection back. If IAT spans through several pages (again, according to DataDirectory[IAT]), then after fixing imports loader will VirtualProtect _all_ that pages with the protection constant which _the_first_ page had).

  4. It’s using the most permissive attributes because everything is in the same page. Try making the file header larger than a page, make the sections really big, etc. You’ll see some different behaviours.

  5. [b]to Peter[/b]
    that was my concern. I thought: if all sections are in the same page and if one of them has “writeable” attribute — Windows has no choice but to make all sections writeable, but I was wrong!!!

    please, consider the following example: http://nezumi-lab.org/ffh/all_writable_pages.zip

    please see:
    char blackhole[1024*8]={1};
    __declspec(naked) nezumi()
    {
    __asm{
    mov ebx, offset blackhole
    mov [ebx], eax
    mov ecx, 90909090h
    call xxx
    xxx: pop eax
    mov [eax], ecx

    also, please see this:
    link.exe all_writable_pages.obj /SECTION:.data,R

    there is no one writeable section at all! and .data section is 2010h bytes long (3 pages), however .text and .data sections could be written!

    well, you can add 4 or 8 thousands of NOP to .text and it will be still working.

  6. I got the small alignment to work after all. It turns out that there are minimum accepted values for the section fields. If the section is too small, or starts too early in the file, then the file won’t load. There’s also a possible anti-debugging trick in there, too… but that needs some further analysis first.

Leave a comment

Comments are closed.