Sign in to follow this  
Followers 0
d3will

OllyDbg

17 posts in this topic

August 03, 2011 - OllyDbg 2.01 alpha 4

As you see, this version already supports plugins.
New plugin interface is similar to the old (v1.10) but 
is not backwards compatible. It includes more than 350
API functions, 60 or so variables and many enumerations
and structures that all need to be documented. 
This will take a while, therefore I decided to make a preliminary release.
It includes plugin header file (plugin.h) and commented
bookmarks source code (bookmark.c). Writing your own 
plugins without the documentation is a pure masochism,
but at least you will be able to analyse the structure
of the interface and  send me your comments, wishes and suggestions .............................
...........................

HomePage

Share this post


Link to post
Share on other sites

If OllyDbg was a comercial product i swear i would bought a copy !

Share this post


Link to post
Share on other sites

glad plugins are now included as this will definitely expand the use of ollydbg and make 1.10 redundant.

Share this post


Link to post
Share on other sites

OllyDbg is great but believe me IDA Pro is much better.

Share this post


Link to post
Share on other sites

Uhm yeah, but you can also download it from the internet :D

Its alot better, really, because you can change everything, update everything, disassemble everything and with the hex-rays decompiler it makes analyzing assembler code alot easier. Its ├╝ber leet :D

Share this post


Link to post
Share on other sites

The difference between OllyDbg and IDA is: OllyDbg is a debugger with disassembler functions. IDA Pro is a disassembler with debugging functions.

For example, you can't tell OllyDbg to reanalyze your code from Offset xyz (thats good if you want to analyze obfuscated code) - in IDA you can do this.

With IDA you can do static analysis of programs, with OllyDbg you can't because OllyDbg runs your program and suspends it.

In IDA Pro you can use Bochs to debug code -> means you will not execute code on your system, it will only be emulated (Bochs Emulator). In OllyDbg you will always execute the Code on your machine -> that's why you should run it in VMWare.

With IDA Pro you can analyze every type of file (binary, linux executables, etc. etc.) in OllyDbg you must run a PE-executable.

And so on ^^

Share this post


Link to post
Share on other sites

OllyDbg 2.01

August 30, 2012 - major update for plugin authors. OllyDbg, Bookmark plugin, preliminary plugin API, test application

I have signifiicantly changed the way OllyDbg and plugins interact with each other. For example, all functions with fixed number of arguments are declared as __cdecl instead of __stdcall. This removes problem with Visual C that always wants to emit something like _Disasm@32 instead of plain _Disasm or Disasm. Otherwise there are only minor changes. Among them, several of OllyBugs are no longer.

Bookmark plugin now works with 4 different compilers: Borland C++ Builder 5.0 (ancient but still my favorite), command-line Borland C++ 5.5 (produces exactly the same DLL), Visual C++ 2005 (Express Edition) and Code::Blocks (in fact, MinGW which is GNU for Windows). There are separate import libraries for each. Plugin source is identical in all cases. I hope that VC library will also work with all otrher Visual versions. Detailed description will be available later - as always...

Help on API is extended but not as far as I expected. Again: If you need some API function or family that is not yet documented, drop me a mail and I'll try to describe it ASAP.

That's all, enjoy!

//http://www.ollydbg.de/

Share this post


Link to post
Share on other sites

//http://www.ollydbg.de/odbg201g.zip

[b]OllyDbg 2.01[/b]
[b]October 04, 2012 - update[/b]

Many bugfixes and several improvements. Plugin interface is still under development.

I've got rid of a very nasty crash. Maybe half of such crashes happened within the [i]GlobalAlloc()[/i], the remaining were almost unpredictable. Of course, it was buffer overflow, what else?

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 [i]KERNEL32.UnhandledExceptionFilter()[/i], [i]NTDLL.KiUserExceptionDispatcher()[/i], [i]NTDLL.ZwContinue()[/i] and  [i]NTDLL.NtQueryInformationProcess()[/i]. For example, if CPU is in the exception handler and you set hardware breakpoint, it won't hit! [i]NTDLL.ZwContinue() [/i]restores original contents of registers and modifications get lost. Therefore OllyDbg sets temporary INT3 break on [i]ZwContinue()[/i] 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 [i]NtQueryInformationProcess()[/i]. 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.

Sometimes it's necessary to rename the OllyDbg, for example if you investigate a brainless virus that scans process names and hopes to avoid debugger. You rename OllyDbg to, say, [i]notadebugger.exe[/i] and... and... and all plugins are missing?! They are statically linked to the DLL named [i]ollydbg.exe[/i]. Of course, [i]GetProcAddress()[/i] would help, but this makes programming to the nightmare. Therefore when OllyDbg loads plugins, it applies a dirty trick which lets Windows think that the main module is named [i]ollydbg.exe[/i] and not [i]notadebugger.exe[/i]. This trick works under Windows XP, but I am not sure whether Vista/Win7 use the same internal data structures. Please check. 

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.

Currently I am working on the plugin interface. Plugins will be allowed to set temporary breakpoints and process exceptions. This requires significant changes in the debugging engine and may take another couple of weeks.

Share this post


Link to post
Share on other sites

http://www.ollydbg.de/

November 19, 2012 - update. OllyDbg, sample plugins, preliminary plugin API, test application

This is a major update of the plugin interface. Now plugins can actively influence the debugging process. They may set temporary breakpoints (Plugintempbreakpoint()) and receive notifications if breakpoint is hit (ODBG2_Plugintempbreakpoint()). If they receive exception notification, ODBG2_Pluginexception() may request to pause application or step over this exception. ODBG2_Pluginnotify() is extended and can force different mode of execution than requested by user.

If necessary, plugin may create one or several options pages in a new Plugins options dialog, which is very similar to the Options. Pluginshowoptions() directly opens plugin-related options page.

There is a new sample plugin, traceapi.dll, that demonstrates new features. It uses one-time memory breakpoints to detect all calls from the user code to the Windows API and protocols the arguments and values returned by APIs. Sample code does not include the Visual Studio project for traceapi. This is despairing - to compile a plugin, I must change several options, like unsigned characters, byte alignment, DLL, UNICODE, import libraries (btw it looks like my VS accepts only absolute paths for implibs!) etc. - TWICE! - once for debug and second time for release configuration. As .vcproj includes GUIDs, I can't simply rename it. Instead, I must recreate new project FROM THE SCRATCH! (yes, all capitals text is a net equivalent of shouting). There is something called "property sheets", but I have found no possibility to save existing options to the property sheet. So if you have a solution to this problem MS feature, please let me know.

Plugin documentation is still far away from finished but is strongly updated.

OllyDbg itself got several bugfixes and minor improvements.

As always, your comments and questions are welcome.

Share this post


Link to post
Share on other sites
I think so as its been updated a lot over the last few months.

I haven't looked at it for ages, I just remember it being a stripped down version of v1.

Share this post


Link to post
Share on other sites

odbg64-03.png

[quote name=

February 05,2014 - the progress is steady.]

Search - 90%

Debugging engine - 70%

Analysis - 15% :(

Slowly, 64-bit version of OllyDbg gets shape. Debugging engine is mostly functional, run trace works well, search is almost ready and dbghelp.dll is more or less integrated. Now I work on analysis. First I thought that this will be easy - ha! Small changes in the command set and different calling conventions force me to rewrite analysis almost from the scratch. So this will take some time.

Share this post


Link to post
Share on other sites

I know the post is a bit date but I don't check ollydbg's site much.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0