blog was moved

Posted in Uncategorized on January 7, 2009 by souriz

blog was movedĀ  to http://nezumi-lab.org

RE-courses/conferences schedule

Posted in courses-n-trainings on September 28, 2008 by souriz


I offer free 3/5/10 days RE-courses for organizations and individuals (examples of the syllabuses will be published soon).

The counties, listed below, are visa-free for me (or give a visa on the border), so they are preferred.

To contact me, please, leave a comment.

  • Barbadoes
  • Belize
  • Colombia
  • Congo
  • Costa Rica
  • Cuba
  • Dominican Republic
  • Ecuador
  • Egypt
  • Fiji
  • Indonesia
  • Iran, Kish Island
  • Israel
  • Jamaica
  • Kenya
  • Maldives
  • Malaysia
  • Morocco
  • Myanmar
  • Namibia
  • Nepal
  • Nicaragua
  • Sesel
  • Sri Lanka
  • Swaziland
  • Thailand
  • Vietnam
  • Yemen

#773: bug in IDA-Pro [fails to debug zero-based PE]

Posted in bugs on May 14, 2008 by souriz

IDA-Pro embedded debugger doesn’t support PE files with zero image base.

the debugger says (I quote):
“IDA Pro couldn’t automatically determine if the program should be rebased in the database because the database format is too old and doesn’t contain enough information. Create a new database if you want automated rebasing to work properly. Notice you can always manually rebase the program by using the Edit, Segments, Rebase program command”.

I have checked 4.7 (standard) and 5.2 (advanced) versions – they are both buggy.

after pressing F9 debugger loses the control, ignores breakpoints (!!!) allowing to the process running on its own, breaking through the debugger!!! really bad news for malware researchers!

to know your enemy – write a simple “hello, world” application and build it as follows:

# ida-bug-773.c
main()
{
ExitProcess (MessageBox (0, “after one bad thing another follows”, “sudah jatuh, ditimpa tangga”, 0));
}

# building ida-bug-773
cl.exe /c /Ox ida-bug-773.c
link.exe ida-bug-773.obj /FIXED:NO /BASE:0 USER32.LIB

ignore linker warning! (after all, it’s just a warning). the file has zero image base, but works fine, coz windows automatically rebases it to the appropriately place. IDA-Pro does rebases files by default, since she doesn’t reserve lowest part of address space like windows does.

to debug the file with IDA-Pro debugger we have to rebase it before debugging: /Edit/Segments/Rebase program/Target, where Target is 0x40000 or something like that. we can use ms editbin.exe tool (if IDA-Pro is unable to rebase the program, however, if the program checks PE-header, it definitely find out that the file was rebased).

# Syser causes BSOD

Posted in bugs on May 9, 2008 by souriz

a new bug in Syser was found. download this file, unpack it and run make-all-and-run.bat.
under XP SP2 with Syser we have BSOD:

# BugCheck 100000D1, {45b0, ff, 0, f580aa75}
# Probably caused by : Syser.sys ( Syser+aa75 )
# DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

this is _very_ strange, since the program causes crash – is a user-mode application, or, to be exactly, there are two programs – one traces another to find out NT bug: OS kernel doesn’t zero TF bit on faults (see this post for more detail), leading to crash OllyDbg, but OllyDbg just refuses to debug, while Syser causes BSOD. not good :=( excellent way to defeat Syser, although :=)

note:
the bug was located
rebuild PeterFerrie.exe with following options and forgot about BSOD:

$link.exe PeterFerrie.obj /ENTRY:nezumi /SUBSYSTEM:CONSOLE KERNEL32.LIB

the previous ones were:

$link.exe PeterFerrie.obj /FIXED /ENTRY:nezumi /SUBSYSTEM:CONSOLE /ALIGN:16 /MERGE:.rdata=.text /STUB:stub KERNEL32.LIB

I’m too lazy to check every combination to find out which one triggers BSOD. it might be /ALIGN:16 or section merging or incorrect ms-dos stub (I just truncated file at the end of MZ-header without fixing size of the file – windows doesn’t check it).

I sent my report to Syser team, but got no answer. never mind. it’s probable nothing. however, the bug gives a great opportunity to malware-writers, so it has to be fixed.

# old CD 03 bug in windows

Posted in bugs on May 9, 2008 by souriz

coming soon!

# turbo-import [stealth anti-api-monitors style]

Posted in optimization on May 9, 2008 by souriz

coming soon!

# bug in Olly, Windows behavior and Peter Ferrie

Posted in bugs on May 9, 2008 by souriz

PeterFerrie strongly disagreed with me, pointed out, that this is not only the Olly bug.

https://www.openrce.org/forums/posts/775#2715:
The not a problem in OllyDbg, it’s a Windows behavior. Try it without any debuggers and you will see the same thing. I found the same while researching my new paper.

https://www.openrce.org/forums/posts/775#2720:
If you set the trap flag then cause an access exception, you’ll get a trap exception before the access exception. That’s the Windows behavior, even without a debugger. Interestingly, it doesn’t happen in a VM. OllyDbg is setting the trap flag before the exception occurs. That’s why you see the behavior. If something else set the flag, you’d still see the behavior.

ok, my bad, he won! I admit it.
to make long story short:
in general, TF-bit is zeroed automatically every time single step exception is generated, so to continue tracing you have to set it again. however, if CPU generates access violation exception, illegal instruction exception or any other fault like this, kernel doesn’t clean TF-bit and keeps it in registry context. after that, kernel cleans TF-bit and calls ntdll!KiUserExceptionDispatcher, KiUserExceptionDispatcher finds and calls SEH-handler(s), gets control back and calls ntdll!NtRaiseException, passing registry context (where TF bit is set!!) as an argument. NtRaiseException asks kernel for passing control to the current process. kernel begins to restore registry context, restoring TF-bit _before_ control is passed. as result – kernel generates single step exception and calls KiUserExceptionDispatcher again, keeping TF-bit unchanged (setting), so, CPU executes the first machine command of KiUserExceptionDispatcher and generates single step exception, passing it to kernel. wow! kernel catches single step exception, cleans TF-bit (wow!!! TF-bit finally is cleaned!) and calls KiUserExceptionDispatcher, passes exception record with context.Eip = (ntdll!KiUserExceptionDispatcher + 1). why plus one? due to single step exception is a trap, not a fault.

how KiUserExceptionDispatcher is supposed to handle this?! well, it just try to find SEH-handler(s), ready to accept this exception and passes control to them. since, expectations are reenterable, everything works fine (of course, if SEH handler is able to handle the unexpected exception of ntdll!KiUserExceptionDispatcher, the best strategy – just ignore it)

but Olly is unable to do this!!! try to trace the program we’re talking about with Olly, trace it until ntdll!KiUserExceptionDispatcher –} ntdll!NtRaiseException and… ops!!! Olly tells you that “debugged program was unable to process exception“.

I recalled that I discovered this windows bug years ago, when I was working on my debugger, but… I just cleaned up TF-bit in the EXCEPTION_DEBUG_EVENT handler and totally forgot about it. and besides, any other debugger does the same – take Soft-Ice for example! (btw, right now I’m porting soft-ice to Vista and Server 2008, making a special bit-hacking patch)

P.S. in few day I’m going to publish more detailed post.