Flag: Tornado!
Hurricane!
|
|
Topic created on: October 10, 2005 01:33 CDT by hoglund  .
Although IDA is good for some things, it remains a static tool and can only focus on a small part of an EXE at a time. While this may be good for some applications, it won't work for those that require cross-DLL analysis, or situations where you need to understand code in the larger context of a process. For those of you who have reversed applications for vulnerabilty -- you can understand this problem. IDA now includes a debugger, but this debugger is still only focused on a single module or DLL and can't collect information from the process as a whole. It obviously very far from collecting from multiple processes.
There is a case for a multi-process, multi-dll analysis tools. Ollydbg doesn't really count since it doesn't come close to IDA in terms of interactivity and program annotation.
Thoughts?
-Greg
I will put in a small plug for my debugger, PEBrowse Interactive, here. The index displays all of the allocated memory and all of the loaded DLLs for the process being debugged. Dumping and disassemblying any address in a single process is trivial. This plus the ability to open multiple memory and disassembly windows comes close to what I think you are asking for in a single process.
Finally, on the few occasions that I have needed to debug multiple processes at one time, the major difficulty for me has been keeping track of context. What I mean by this is if breakpoints have been set in all of the processes and one of them is triggered, it takes a moment to figure out where the breakpoint has fired and sometimes even longer to understand why.
|
In general, I find myself analyzing DLLs one at a time. There are definetely cases where it would be convenient and helpful to be able to go cross-DLL within a single instance of IDA.
That being said however, I prefer OllyDbg over IDA's debugger. A possible solution to this would be to use a tool like IDA/Olly Sync, a new version of which is in the works. I will add a feature to synchronize multiple IDA windows to a single instance of Olly.
Is this something along the lines of the kind of solution you were thinking about?
|
|
I find Olly to be very useful and well beyond IDA in terms of a debugger, but for whatever reason, the user interface in Olly is a major setback. Now, I'm not one to be held back from a good tool - I use Softice in 80 column video mode too (eck) - but I think alot of people use IDA primarily for it's rather 'snappy' user interface. If olly had easier to use labelings and assembly browsing, I wouldn't even need IDA anymore. All the basics are already there, xrefs, symbols, and it sports a fairly robust plugin cabability too. At least, I _think_ I wouldn't need IDA anymore. I guess it has structures - it would be hard to get by without the structures window.
|
Hi Greg,
I brought this issue up *years* ago (2000 I think) on the IDA board. You may want to search the archives there.
The only tools I have used to deal with multi-process analysis/debugging are TotalView and Vampir. These tools are built specifically for the HPC world (High Performance Computing a.k.a. "super computers" and "clusters"). In general they are geared towards finding and eliminating bottle necks in multi-process code and like everything in the HPC world, they are insanely expensive.
The only reason I got a chance to play with them is because prior to the attacks on 9/11, the Maui High Performance Computing Center (MHPCC) allowed regular people to take courses (assuming said regular person doesn't mind having one or two people watching everything you type). These days you need a security clearance to just enter the facility.
Another place to look is the world of system/cluster simulation/emulation. You can do some amazing things when you can stuff all your processes into a virtual cluster of systems and halt/start the whole thing. The product that comes to mind is called Simics by Virtutech. It's basically VMware on steroids for those who happen to have a spare 50 to 100 thousand to spend on software.
There are probably a lot of other similar things now available in the HPC world (possibly as F/OSS) since I haven't really been keeping up with it.
Kind Regards,
JCR
|
In general, I find myself analyzing DLLs one at a time. There are definetely cases where it would be convenient and helpful to be able to go cross-DLL within a single instance of IDA.
I included an example in my tutorial that loaded any DLL mentioned in the strings section (possibly an argument to LoadLibrary() at some point). This enables you to load the executable as well as the DLLs it uses into the one IDB:
http://www.binarypool.com/idapluginwriting/loadlib.cpp
Hope that's what you're after.
|
|
I tend to prefer doing mostly static analysis in IDA, and then using Olly to quickly trace a piece of complicated code that I can't figure out statically in IDA. Usually I use them simultaneously, and I use IDA to analyze the code, and Olly to trace through it and examine the internal state of the program at each step. I think relying solely on one or the other is a big mistake.
|
This is actually one area where I plan on improving on existing tools in OpenREF. The goal is that analysis can be done as needed (much like OllyDbg) and that you will have more control over what gets analyzed at a given point in time so that you neither have too much data (causing slowdowns) nor too little (causing more work for you).
I'll post here asking for input on different portions of OpenREF as they come up, for sure.
(And yes, I'm sure that all of what I've said about OpenREF is making it sound like vaporware, and that's due to the fact that it's nowhere near that point yet. These features are quite a while into the future. When it gets to the point that they start being viable to implement, things will be far more concrete rather than just "OpenREF will ...")
-Cody.
|
For multi-DLL on windows, I simply use Atli's PE scripts (available here) and load all relevant DLLs into IDA. For dynamic analysis, I then use BinNavi. You might want to run a few scripts to fix some cross refs between executables, and for non-PE targets an IDAPython ELF loader :)
Works for me.
Cheers,
Halvar
|
We are evaluating binNavi 1.2 version, but i have some questions. I'm debugging IE7, concretely the libraries msls31.dll and mshtml.dll. I load idb of IE7 in BinNavi, but this idb haven't got msls31 and mshtml dll's, so i can't see the execution graph throw these dll. I have probe to use Atli's PE scripts against IE 7, loading these libraries in the IE idb database. Then i import the idb to binnavi, launch the DebugClient, and start recording, but the DebugClient died:
Waiting for connection...
Wait_For_Connection: Entering ...
About to call accept
Wait_For_Connection: accepted connection (784).
Got connection...784
Resuming thread : 0..
Is there same ways to debug this dll's?
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}