I'm a systems programmer trying to educate myself on the nitty gritty of reverse engineering and low-level injection vulnerabilities. I'm currently studying this proof of concept http://milw0rm.com/exploits/9579 for Adobe Reader 9.0 http://www.oldapps.com/adobe_reader.php?old_reader=18. It didn't work when I applied the included dummy exploit PDF (Reader just crashes), so I'm using OllyDbg to figure out what's going on. (Yes, I cleared the ASLR and NX bits on AcroRd32.exe to make this whole operation feasible.)

The vulnerability is in Annots.api, but I can't figure out how to have OllyDbg load that, then execute AcroRd32.exe. I'm also not sure how to navigate to that basic block pointed out in the PoC's report so as to set a breakpoint there - the address is apparently 0x2210FCE8 (as shown by some version of IDA Pro), but the only addresses I see are 0x00404054.

Any other hints on what I should be doing to debug the exploit would be much appreciated. Thanks in advance.

Hi

Welcome to the board, just to let you know, embedded URL's aren't supported in the forums (except for the Blogs Forum), so I edited your post to make the links visible.

I'm not really familiar with analysing these type of exploits, but I was playing around with it a bit. What you could try is to let Acroread open fully under Olly, explore and set your breakpoints in Annots.api, THEN open the exploit pdf.

What I *was* going to say was:

Select View/Executable modules in Olly, right click on the fully loaded Annots.api, select View Names, scroll down to the vulnerable strncpy() used in the exploit, right click and select Find References to Import, and you'll get a list of addresses where the import is called. This should direct you where you want to be.

I thought this would work in theory, but I seem to have a problem with Olly + AcroRd32. Initially AcrodRd32 was running, but as soon as I started manipulating windows in Olly (such as selecting View Names and scrolling the window) it Paused and I couldn't restart the debuggee. Instead it gave me an unrecoverable access violation in RPCTR4.

You could try this, but if you have problems as well you might try the similar idea in WinDbg.

Kayaker

OK, I got around the continual glitching by Olly with AcroRd32 in the following way:

Let Olly load AcroRd32 completely, F9 after breaking at WinMain to allow all the other dlls to load.
In AcroRd32, open the file dialog box and point to the exploit pdf to load - BUT DON'T LOAD IT YET.
Go back to Olly and select Options/Debugging Options/Events/Break on new module (DLL).
Now go back to AcroRd32 and finish loading the pdf file.
Following this sequence prevents Olly from unnecessary breaks which might glitch the overall loading process with an unhandled exception.


Olly will break on each new dll being loaded, follow the action in both the Executable Modules window and the Log window. F9 a few times and you will catch the exploit dll being extracted to "C:\Documents and Settings\..\Local Settings\Temp\PWN**.tmp". Make a copy of it now if desired.

Select PWN**.tmp in the Executable Modules window and press Enter, the CPU window will display the Entry Point - F2 to set a breakpoint here. Scroll down and also set a breakpoint at the start of DllMain.

switch (ul_reason)
{
case DLL_PROCESS_ATTACH:
CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)CustomMessageBox, NULL, 0, &r);


Now you can F9 and Olly should break on DllMain, where you can start your tracing. Also set a breakpoint on the CreateThread address before tracing over the API.

With this method I could control the complete execution of the exploit dll, including watching the winsock dlls load during payload() with the Break on new module (DLL) setting still enabled.