exploiting-deserialization

Exploiting Deserialization

Deserialization turns attacker-controlled bytes into live objects with attacker-chosen types. The vulnerability is not the parsing — it is that constructing those objects runs code paths the developer never intended. The work is recognizing the format, then finding a gadget chain in the libraries that happen to be on the classpath.

Only against systems you are authorized to test.

When to Use

• A cookie, parameter, header, or message body contains a serialized object
• You see the magic values listed below in traffic or storage
• Source review finds readObject, unserialize, pickle.loads, Marshal.load, BinaryFormatter, yaml.load, or ObjectInputStream
• A message queue, cache, or session store holds serialized objects
• You need to confirm a suspected blind deserialization

When NOT to Use

• JSON/XML parsing without object instantiation — that is injection or XXE; use testing-web-applications
• Source-code review as the primary task — use auditing-code-for-vulnerabilities; return here for exploitation
• Building a weaponized payload beyond proving impact — prove control, stop
• Analyzing malware that uses deserialization — use analyzing-malware

Recognize the Format

Magic bytes identify the runtime, and the runtime decides the entire approach.

Encoding	Base64 prefix	Raw bytes	Runtime
Java serialization	rO0AB	AC ED 00 05	Java
.NET BinaryFormatter	AAEAAAD/////	00 01 00 00 00 FF FF FF FF	.NET
.NET LosFormatter/ViewState	often /wEP	—	ASP.NET
PHP serialize()	Tzo, YTo	O: , a:	PHP
Python pickle	gAJ, gASV, KGRw	80 04, 80 02, (dp	Python
Ruby Marshal	BAh	04 08	Ruby
Java Hessian/Burlap	Yw	63/48	Java
YAML with tags	—	!!python/object, !ruby/object	Multiple

# Decode anything suspicious you find
echo 'rO0ABXNyABNq...' | base64 -d | xxd | head -3

# Java: readable class names appear in the stream
echo '<b64>' | base64 -d | strings | head -20