scdbg vrs ROP


Author: David Zimmer
Date: 02.18.13 - 4:54am





with this latest Adobe exploit (with sandbox escape no less) the question comes up how do we analyze ROP chains and is it something that scdbg can work with. Up until now they have just been gadgets and could be ignored. Findsc would happily bypass the gadget and locate the real shellcode start offset and all was good.

If we begin to see more ROP only shellcode we will have to figure out easy ways to deal with it. So I ran some experiments with scdbg to see what I could do.

It took a couple new options to experiment with it. First I had to add a new /raw mode to load raw byte buffers into emu memory, and a new command line /poke option to load dwords. (these are like command line versions of the -patch file functionality with /raw better suited to large data blocks)

Then I had to add a -rop mode that sets esp to be the -offset you specify, and starts execution with an appended ret command to start the rop flow. (I also added the ability to drag and drop .scmd files onto the exe to run as command lines.)

Now except for kernel32 and ntdll, I currently dont include all the dll opcodes in the emu memory to keep distribution size smaller. (Those two are included to support opcode return address scanners). So if the ROP chain uses a supported dll such as msvcrt or advapi etc right now we have to manually load the .text section with -raw and any used IAT entries with -poke.

This is fine for experimentation and enough to see if I want to pursue this course or if I want to use a different approach for ROP analysis.

The other approach I have in mind, is to attach the actual target process with iDBG and extract/disasm the memory pointed to by the ROP chain or just let it single step and generate a trace.

I also experimented with using the SysAnalyzer Api_logger.exe to inject target dlls (such as acroform.api) into the target process to help set it up and thinking about adding a feature to the app to inject data sections as well such as the ROP chain itself for out of exploit analysis of them.

Its an interesting thought on how to analyze rop chains out of the context of the actual exploit.

I already pushed the update to github repository where you can always download the latest build. An example command line to use with corelanc0d3r advapi ROP chain would be
scdbg -f advapi_rop.sc -rop -raw 0x77dd1000-c:advapi.text.dat -poke 0x77dd1404-0x7c90dc9e
You can download the sample files and .scmd command lines here.

Another question is will we see many more ROP only shellcodes? I havent done any research into generating ROP only payloads. It was clearly a lot of work for them to generate these ones. "These" being said because they are incredibly dll version specific and the one exploit contained ROP chains for 11 possible versions of the dll.

Also, this would not have been possible if they didnt have a way of detecting the exact dll version (via an info disclosure bug). And finally, they had a whopping 10mb dll to use to generate their chains which offers a boat load of possibilities. (I havent analyzed their chain yet to see how much they used or if they just kept it to basics).

The leavel of weaponization on this one was really impressive. I cant really imagine it was worth the labor though. Depends on who their initial target I guess. Is this known?

As i have been playing catch up on ROP here are a bunch of good articles on it:




Comments: (0)

 
Leave Comment:
Name:
Email: (not shown)
Message: (Required)
Math Question: 25 + 88 = ? followed by the letter: A 



About Me
More Blogs
Main Site
Posts: (All)
2023 ( 4 )
2022 ( 5 )
2021 ( 2 )
2020 ( 5 )
2019 ( 6 )
2017 ( 5 )
2016 ( 4 )
2015 ( 5 )
2014 ( 5 )
2013 (9)
     Guest Post @ hexblog
     TCP Stream Reassembly
     SysAnalyzer Updates
     Apilogger Video
     Shellcode2Exe trainer
     scdbg updates
     IDA Javascript w/IDE
     Rop Analysis II
     scdbg vrs ROP
2012 ( 13 )
2011 ( 19 )
2010 ( 11 )
2009 ( 1 )