There are lots of corner cases and obfuscated binaries that ‘fool’ your analysis and things get especially fuzzy when control flow branches inside of other instructions or otherwise breaks the linear disassembly.Įven if you have a really good debugger and code analyser, you are still far from done. Analysis is really, really hard to get working right.
Some more involved algorithms are available here (by me) and here (by Nukem). If you’re interested I wrote up the details of a very naive algorithm here. The hard part is actually doing control flow analysis (detecting functions and loops for instance). An all-white deadlisting of instructions is not very friendly to read and OllyDbg does various things to ease the experience. The ‘easy’ part involves giving information about instructions pointing to memory/exported symbols and providing nice syntax highlighting. The code analysis is a far more difficult problem to solve. It is a debug library that will be used in 圆4dbg soon. If you are interested in a little more detail, check out GleeBug. Certain events (mainly single-step and breakpoint exceptions) are used to control the execution of the debuggee. The debugger then processes these events and shows information about the process to the user. In essence you start a process (debuggee) with a special flag so it sends information (debug events) to the debugger. Check out Creating a Basic Debugger for a simple example of what a debugger looks like. The debugger part starts out quite simply. As of my qualifications, I’m the main developer of 圆4dbg, which is heavily influenced by OllyDbg and offers similar features but on the 64-bit platform.
OllyDbg is in essence a debugger with code analysis features, however it has a big range of relatively small extra features that make it a nice thing to use. Writing a tool like OllyDbg is not a trivial task. I thought it was interesting so I decided to cross-post it here as a blog entry: Today I wrote an answer on Quora about how OllyDbg was written.
0 kommentar(er)
