OpenRCE

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!

Created: Monday, December 10 2007 12:58.47 CST

Printer Friendly ...

Binary Protocol Dissector

Author: jms

# Views: 5466

Well today is the last day for the ID contest, and I am interested to see what kind of competition there is out there! Unfortunately, like a dummy, I wasn't regression testing my plugin over the past few releases. Although it was done months ago, it doesn't work now :(

Soooo.... I thought I might as well share what it is and what it does, and if by some Christmas miracle I get it working by midnight tonight it will be submitted.

The whole idea of the plugin is to be able to automate the task of reverse engineering a protocol so that you can easily translate it's structure to a block-based fuzzer (like Sulley or SPIKE).

Essentially, it has two components: mike.py and boo.py (for Monsters Inc. fans of course :))

mike.py - this hooks socket calls, and when a packet arrives it begins single-stepping and trapping all state information as the packet traverses through the process space. Using some simple heuristics, it is able to determine when the packet length and packet payload is being used by the process. A lot of logic was built in to output GDL graphs of all the information it has trapped. Using a threshold for each iteration it is able to graph deeper and deeper into the protocol.

boo.py - this is responsible for sending the packets themselves, and is to be extended so that when mike reports a hit on the packet payload (during a CMP instruction for example), boo will adjust its test packet to try to meet the protocol criteria.

So, since it's busted and I can't get some of the small niceties cleaned up I figured the minimum is to post some graphs.

Here is a graph of the first iteration against the Perforce source code repository server.

A bit anti-climactic isn't it! So let's zoom in a bit further:

Now you can see some more information! Yay! (if only I could get this bloody thing working again...ok I will stop complaining). Let's see what our second iteration looks like from a high level:

You can see the blocks that were covered previously are greyed out, so that you can drill down into your newly covered area:

So yeah, I will repost if I get it working, but that's it! A

Blog Comments

PSUJobu	Posted: Tuesday, December 11 2007 07:17.51 CST
Very intriguing! Hope you get it (or got it) working! Good work...

jms	Posted: Tuesday, December 11 2007 12:13.35 CST
Yeah I got it working, however I ran out of time to get some of the more advanced packet matching/replay stuff done.

There are 31,311 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
hi!	Jul/01
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

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