offensive-deserialization

# Offensive Deserialization Deserialization vulnerabilities arise when an application reconstructs objects from serialized byte streams without validating the type, integrity, or origin of the data. Object reconstruction triggers constructors, finalizers, and language-specific magic methods, so an attacker who controls the serialized input often achieves remote code execution before any application-level validation runs. ## Quick Workflow 1. Enumerate every entry point accepting opaque binary or encoded data -- cookies, HTTP bodies, headers, message queue messages, file uploads, GraphQL custom scalars, gRPC fields, JMX/RMI endpoints. 2. Fingerprint the serialization format via magic bytes, content-type headers, and error behavior (see Recognition Signatures). 3. Determine the server-side language and framework version from error pages, HTTP headers, or source code. 4. Select candidate gadget chains matching the target classpath or installed packages. Generate payloads with ysoserial, phpggc, ysoserial.net, or manual construction. 5. Deliver through the identified entry point. Start with DNS-only or sleep-based proof to confirm execution without destructive side effects. 6. Escalate from proof-of-concept to the engagement objective with authorization. 7. Document the full chain: entry point, format, gadget chain, library versions, proof. --- ## Recognition Signatures | Format | Signature | Notes | |---|---|---| | Java ObjectInputStream | Hex `ac ed 00 05`...