OpenRCE

📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Check Out

ASM Bots: Core War, rebooted. x86 bots fight in shared memory. asmbots.io

Created: Thursday, March 27 2008 15:15.41 CDT

Direct Link, View / Make / Edit Comments

BlackHat Europe

Author:

pedram

# Views: 10750

Ero and I finished up our two day Reverse Engineering course yesterday and caught up on some much needed sleep after a few drinks at some local pubs. Got a chance to catch some of the talks today prior to flying out tomorrow morning to Barcelona for the weekend.

FX had a well researched talk on Cisco IOS forensics that I greatly enjoyed. It appears the boys over at SABRE/Recurity have put together a pretty robust Cisco core dump analyzer and to my surprise they have made it available for use free of charge:

http://cir.recurity-labs.com

The other event I really enjoyed today was the
Iron Chef challenge. Apparently they had one of these at the Vegas Black Hat show, I had no idea. Essentially 2 teams are presented with a target and given 45 minutes to audit it. Their results are judged at the end of the 45 minutes by the audience and a winner is chosen. The chosen target was JForum, a web forum written in Java. The audience is allowed to play along; Neither Java nor web apps are my forte but I was playing around on Ero's laptop for a few minutes and found a persistent script injection flaw. Nothing too exciting but the contestants didn't do much better coming up with only a few theoretical possibilities. All in all I really like the idea of this Iron Chef track. They should provide a little more time and do something with binary analysis, that could be fun.

There are some great talks lined up for tomorrow that unfortunately I will be missing. I was especially excited about the DTRACE talk but was unable to change my flight.

Created: Thursday, August 23 2007 00:56.17 CDT

Modified: Thursday, August 23 2007 00:56.35 CDT

Direct Link, View / Make / Edit Comments

PyDbg Hacks

Author:

pedram

# Views: 16253

Just added some PyDbg based hacks to the public repository (should show up within an hour max of this post). Here is a description of what was added:

just_in_time_debugger.py
PyDbg implementation of a script that can be set as the Just-In-Time debugger. Logs the crash context to disk. I'll be blogging about / giving out a standalone executable based on this script for those of you who want to e-mail all your crash dumps to ... me ;-)

stack_integrity_monitor.py
Automatically locate the source of a stack overflow. This has already been released, just hasn't been previously part of the repo. For more info see the related blog entry.

pydbgc.py
Cody's PyDbg command line interface library. This is pretty cool, you can import it to drop a user into an interactive PyDbg shell at any point during execution. Gives you WinDbg-esque commands. One of the cooler features of this hack is that it allows you to step backwards, really.

push_pop_unpacker.py
This is a quick and dirty PyDbg implementation of a known generic technique for stopping an unpacker at OEP. This script was written during Ero and I's 2007 Reverse Engineering class at BlackHat. It took like 20 minutes to write, gotta love PyDbg.

null_selector_mem_monitor_poc.py
Pydbg implementation of skape's null selector mem-monitor technique. Read more about it on Uninformed Journal

Get all the new goodies at http://paimei.openrce.org.

Created: Tuesday, July 24 2007 23:20.43 CDT

Modified: Tuesday, July 24 2007 23:27.43 CDT

Direct Link, View / Make / Edit Comments

iPhone Gripes

Author:

pedram

# Views: 11332

Based on Apple's history of releasing crappy first-rev products I was going to wait for the next release prior to purchasing the iPhone. An unfortunate drunken phone accident this weekend however accelerated my purchase plans.

First, I'll say something nice. The visual voicemail feature of the iPhone is very elegant. I deplore voicemail, to the point that anyone who knows me well knows to never leave me one. With the iPhone I actually look forward to voicemail now. You get a list of who called and at what time. You can click to play, fast forward, rewind. It's how voicemail should be. None of the nonsense of "hit 1 to listen to new messages, 3 for the next, 7 to erase....".

Now the ugly. What were the iPhone devs smoking when they made the following oversights:

* No custom ring tone. A $650 device with 8 gigs worth of mp3's and I'm limited to choosing between sounds such as a dog bark and a duck?

* Proprietary headphone jack. Why couldn't they make the jack cross-compatible with standard head phones? Probably because they want to up-sell you on cute, white, headphone adapters.

* No copy and paste. Manually typing in WEP keys sucks. Aside from that I could have maybe lived without copy/paste ... until I discovered the next atrocity.

* NO GROUP OR MULTIUSER TEXT MESSAGING! This is completely unacceptable. Every cell phone on the face of the planet has this capability. I'm especially upset about this because I text like a 16 year old girl. Organizing outings, after parties, etc. without group texting is next to impossible.

* Keyboard doesn't flip sideways. Flipping the phone sideways does not flip the keyboard sidways (unless you are in the browser). Typing on the widescreen keyboard is much easier and should be available for texting and e-mails. Retarded.

How's everyone else doing with theirs?

Created: Friday, July 6 2007 19:18.00 CDT

Direct Link, View / Make / Edit Comments

Greatest Book Dedication Ever?

Author:

pedram

# Views: 13964

Not to brag or anything, but who can deny this as the greatest book dedication the world has ever seen:

Fuzzing: Brute Force Vulnerability Discovery - Dedication

If you are interested in buying the book:

Amazon

Created: Tuesday, May 8 2007 23:35.21 CDT

Direct Link, View / Make / Edit Comments

Pin Pointing Stack Smashes

Author:

pedram

# Views: 11627

This was originally posted over on my company blog site (TippingPoint DVLabs). Since the DVLabs blog is new I'm cross posting here to draw some traffic to it. Tracking down stack overflows is tedious work. Especially when the entire stack is blown away leaving you with crash dumps like the excerpt following this paragraph. This crash dump is from an actual process in case you are curious. Specifically, it is from one of the bugs detailed in TPTI-07-02: Trend Micro ServerProtect eng50.dll Stack Overflow Vulnerabilities. It's pretty obvious that it's game over for our target here. The important question to answer at this juncture is, where is the bug? There are a number of approaches you can take to manually handle this situation. Please add any creative ones you may have as a comment.



    [INVALID]:41414141 Unable to disassemble at 41414141 from thread 568

    caused access violation when attempting to read from 0x41414141

    

    CONTEXT DUMP

      EIP: 41414141 Unable to disassemble at 41414141

      EAX: 00000001 (         1) - N/A

      EBX: 0259eedc (  39448284) - AAAAAAAAAAAAA.....AAAAAAAAAAAAAAAAAAAAA (stack)

      ECX: 00000000 (         0) - N/A

      EDX: ffffffff (4294967295) - N/A

      EDI: 00000000 (         0) - N/A

      ESI: 0259f102 (  39448834) - AAAAAAAAAAAAA.....AAAAAAAAAAAAAAAAAAAAA (stack)

      EBP: 00000001 (         1) - N/A

      ESP: 0259e2d4 (  39445204) - AAAAAAAAAAAAA.....AAAAAAAAAAAAAAAAAAAAA (stack)

      +00: 41414141 (1094795585) - N/A

      +04: 41414141 (1094795585) - N/A

      +08: 41414141 (1094795585) - N/A

      +0c: 41414141 (1094795585) - N/A

      +10: 41414141 (1094795585) - N/A

      +14: 41414141 (1094795585) - N/A

    

    disasm around:

            0x41414141 Unable to disassemble

In this blog entry, I present stack_integrity_monitor.py. A command line utility implemented in under 150 lines of Python code which provides an automated solution to the task of tracking down the source of a stack overflow. This Python utility leverages PyDbg, a pure-Python win32 debugger interface. PyDbg is part of the larger PaiMei Reverse Engineering Framework. If you've never heard of PaiMei before, follow the link to learn more.

The main reason stack overflows are exploitable is because control information is stored in the same medium as volatile user-controllable data. If we can move or mirror the call-chain "out of band", then we can verify the integrity of the stack at run-time. Skipping over the intricate details, here is the high level overview of how the utility works:

   1. Instantiate a debugger object and attach to the target program.
   2. Set a breakpoint where we want the trace to start, this can be as simple as setting a break on recv().
   3. Once the breakpoint is hit, set the active thread to single step.
   4. When a CALL instruction is reached, copy the stack and return addresses to an internal "mirror" list.
   5. When a RET instruction is reached, walk through the "mirror" list and verify that the values match the actual stack.
   6. When the last saved return address is reached, pop it off the internal "mirror" list.

If during the stack integrity check a mismatch is found, then not only do we know that a stack overflow has occurred, but we know which functions frame the overflow originated in and we can pinpoint the cause of the overflow. Using Trend Micro again as a real-world example, the previously shown (and mostly useless) crash dump turns into the following (very useful) output when launching the target under the peering eyes of stack_integrity_monitor.py:



    0259fc24: TmRpcSrv.dll.65741721

    0259e7b4: StRpcSrv.dll.65671190

    0259e7a8: Eng50.dll.61181d8c

    0259e790: Eng50.dll.611819a0

    0259e564: Eng50.dll.61181a50

    0259e2d0: Eng50.dll.61190fa4 -- 41414141

    0259e03c: Eng50.dll.61190fd2

Examining the vicinity of the last return address in the list, we find:



    61190FC7 lea edx, [esp+288h+szShortPath]

    61190FCB push esi

    61190FCC push edx

    61190FCD call _wcscpy  

    61190FD2 add esp, 8

The wcscpy() is the source of the stack overflow. The origin of the overflowed buffer is obvious in this case, it resides in the current function frame with a size of 600 bytes. Had the overflow occurred in a buffer originating further up the call chain the stack_integrity_monitor would have told us. In this case we see the stack mismatch occurred at stack address 0x0259e2d0 which should contain the return address 0x61190fa4 but instead contains 0x41414141. Had even a single byte of the return address been overwritten, stack_integrity_monitor would have detected it.

This handy command line utility has been checked into the PaiMei SVN repository and will be distributed with future releases of the reverse engineering framework. Future improvements may include speed boosts and perhaps additionally mirroring saved frame pointers. This quick hack was written in less than 2 hours and motivated from necessity, on a day where I happened to need to track down a dozen or so stack overflows. Give it a try, let me know what you think.

Archived Entries for pedram

Subject	# Views	Created On
Branch Tracing with Intel MSR Registers	152229	Wednesday, December 13 2006
Pcapy (Sniffing) on WiFi	3506	Saturday, December 9 2006
Owning Computer Associates BrightStor through Mailslots	3357	Thursday, October 5 2006
eEye Binary Diffing Suite (EBDS)	5135	Thursday, August 10 2006
PaiMei Hooking Library	6561	Tuesday, July 18 2006
Microsoft Ring0 Vulnerability++	6526	Tuesday, July 11 2006
RECON2006 - PaiMei Release	2885	Friday, June 16 2006
ShmooCon 2006	3129	Monday, January 16 2006
Debugger Debugging Madness	4861	Friday, January 6 2006
IDA Disassembly and Graph Coloring	4194	Friday, December 2 2005
IDA Customizations	3930	Wednesday, November 2 2005
ToorCon 7 Review	1743	Tuesday, September 20 2005
I Survived Vegas	2298	Monday, August 1 2005
MS05-025 PNG Image Rendering Vulnerability	1543	Tuesday, June 21 2005
OpenRCE Site Launch	2045	Friday, June 17 2005

There are 31,328 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06
Question about memor...	Dec/12

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit