Special highlights are:
Changes made to OllyDbg 2.01:-
Debugging engine is now more stable, especilally if one steps into the exception handlers. There is a new debugging option, “Set permanent breakpoints on system calls”. When active, it requests OllyDbg to set breakpoints on KERNEL32.UnhandledExceptionFilter(), NTDLL.KiUserExceptionDispatcher(), NTDLL.ZwContinue() and NTDLL.NtQueryInformationProcess(). For example, if CPU is in the exception handler and you set hardware breakpoint, it won’t hit! NTDLL.ZwContinue() restores original contents of registers and modifications get lost. Therefore OllyDbg sets temporary INT3 break on ZwContinue() and applies changes to the copy of the context in memory. But sometimes it simply doesn’t know that temporary breakpoint is necessary. If process is being debugged, Windows don’t call the unhandled exception filter. Instead, it notifies debugger. To pass exception to the filter, OllyDbg intercepts NtQueryInformationProcess(). If handler asks OS whether process is debugged, OllyDbg reports “no”. And so on. Well, if this new option is so advantageous, why not to make it default? Because some viruses check for INT3 breakpoints on these APIs.
A very nasty buffer overflow leading to a crash was also resolved that happened within the GlobalAlloc() function.
Another exciting feature brought out for malware researchers is that causes OllyDbg to load plugins which lets Windows think that the main module is named ollydbg.exe and not notadebugger.exe. Previously, if you renamed OllyDbg to, say, notadebugger.exe and that would cause all plugins not to be detected.
Hit trace can be saved between the sessions. If code is self-modifiable, use this option with care. When OllyDbg restores hit trace, it sets INT3 breakpoint on every marked command. This may lead to crash of the debugged application.
Due to the invalid handling of prefixes 66, F2 and F3, command search was unable to find SSE commands. This bug is corrected.
- Intuitive user interface, no cryptical commands
- Code analysis - traces registers, recognizes procedures, loops, API calls, switches, tables, constants and strings
- Directly loads and debugs DLLs
- Object file scanning - locates routines from object files and libraries
- Allows for user-defined labels, comments and function descriptions
- Understands debugging information in Borland® format
- Saves patches between sessions, writes them back to executable file and updates fixups
- Open architecture - many third-party plugins are available
- No installation - no trash in registry or system directories
- Debugs multithread applications
- Attaches to running programs
- Configurable disassembler, supports both MASM and IDEAL formats
- MMX, 3DNow! and SSE data types and instructions, including Athlon extensions
- Full UNICODE support
- Dynamically recognizes ASCII and UNICODE strings - also in Delphi format!
- Recognizes complex code constructs, like call to jump to procedure
- Decodes calls to more than 1900 standard API and 400 C functions
- Gives context-sensitive help on API functions from external help file
- Sets conditional, logging, memory and hardware breakpoints
- Traces program execution, logs arguments of known functions
- Shows fixups
- Dynamically traces stack frames
- Searches for imprecise commands and masked binary sequences
- Searches whole allocated memory
- Finds references to constant or address range
- Examines and modifies memory, sets breakpoints and pauses program on-the-fly
- Assembles commands into the shortest binary form
- Starts from the floppy disk
Changes made to OllyDbg 2.01:-
Debugging engine is now more stable, especilally if one steps into the exception handlers. There is a new debugging option, “Set permanent breakpoints on system calls”. When active, it requests OllyDbg to set breakpoints on KERNEL32.UnhandledExceptionFilter(), NTDLL.KiUserExceptionDispatcher(), NTDLL.ZwContinue() and NTDLL.NtQueryInformationProcess(). For example, if CPU is in the exception handler and you set hardware breakpoint, it won’t hit! NTDLL.ZwContinue() restores original contents of registers and modifications get lost. Therefore OllyDbg sets temporary INT3 break on ZwContinue() and applies changes to the copy of the context in memory. But sometimes it simply doesn’t know that temporary breakpoint is necessary. If process is being debugged, Windows don’t call the unhandled exception filter. Instead, it notifies debugger. To pass exception to the filter, OllyDbg intercepts NtQueryInformationProcess(). If handler asks OS whether process is debugged, OllyDbg reports “no”. And so on. Well, if this new option is so advantageous, why not to make it default? Because some viruses check for INT3 breakpoints on these APIs.
A very nasty buffer overflow leading to a crash was also resolved that happened within the GlobalAlloc() function.
Another exciting feature brought out for malware researchers is that causes OllyDbg to load plugins which lets Windows think that the main module is named ollydbg.exe and not notadebugger.exe. Previously, if you renamed OllyDbg to, say, notadebugger.exe and that would cause all plugins not to be detected.
Hit trace can be saved between the sessions. If code is self-modifiable, use this option with care. When OllyDbg restores hit trace, it sets INT3 breakpoint on every marked command. This may lead to crash of the debugged application.
Due to the invalid handling of prefixes 66, F2 and F3, command search was unable to find SSE commands. This bug is corrected.
Download OllyDBG:
OllyDbg 2.01 – odbg201g.zip
OllyDbg 2.01 – odbg201g.zip
Source -
Good blog.I am really grateful for this.
ReplyDeleteEveryone can have a look at Finding a way of Security systems