Binaries

Binary exploitation is the process of finding and exploiting vulnerabilities in compiled software (binaries) to alter its intended behavior, often to gain unauthorized access or execute arbitrary code.

Unstripped refers to a binary that still contains its symbol table and debugging information, such as function names, variable names, and file paths—making reverse engineering and debugging significantly easier.

Binary markers

Packing

A packer is a tool (or library) that transforms an executable so that its original code and data are compressed and/or encrypted, then wrapped inside a small “loader stub.” When you launch the packed binary, the stub decompresses or decrypts the real code in memory and then transfers execution to it.

Why it’s used

  1. Protection/Obfuscation: Makes static analysis much harder—disassemblers see only the stub and an opaque payload, not your original code.
  2. Anti-malware evasion: Malware authors pack their payloads so that signature scanners can’t directly match known code.
  3. Size reduction: Some legitimate packers (e.g. UPX) were originally designed to compress executables to save disk space.

How it works

  1. Compression/Encryption: The original .text and/or .data sections are run through a compressor (like LZ77) or cipher.
  2. Stub insertion: A small loader stub—often in the new entry point—contains routines to (a) allocate executable memory, (b) unpack the payload there, and (c) jump into the real entry point.
  3. Runtime unpacking: At runtime, control briefly resides in the stub; after unpacking, the process image in memory looks like the original program.

Reversing a packed binary

  1. Identify the packer: Signatures (PE sections named e.g. .upx, imports like VirtualAlloc) can clue you in.
  2. Dump the unpacked image: Either let the stub run under a debugger and then dump memory once the payload is decoded, or use an automated unpacker/unpacker script.
  3. Analyze the real code: Once you have the unpacked dump, reload it into IDA/Ghidra with adjusted entry points and imports.

Blob

A “blob” refers to a large, opaque chunk of binary data whose internal format or purpose is not immediately obvious. There are a few contexts where you’ll see “blobs”…

Firmware or resource blobs

In firmware images (UEFI, routers, embedded devices), you might see sections labelled .blob or simply as huge “binary resource” areas. These could contain compressed filesystems, device-tree blobs, or proprietary data.

You’ll have to identify magic numbers or filesystem headers (e.g., SquashFS, JFFS2) and extract them with specialized tools.

Encrypted or packed payload blobs

Within a packed executable, the payload itself is a “blob” of compressed/encrypted bytes.

Until you unpack/decrypt it, all you see is a blob—no functions, no strings, just raw data.

Data blobs in memory

Advanced malware sometimes allocates giant blobs in memory to hide shellcode or configuration data.

You’ll treat it as a byte array and reverse it by pattern-matching, XOR guesses, or emulating decryption routines.

Challenges with blobs

  1. No structure or symbols: You often have to manually hunt for known headers, magic constants, or entropy patterns.

  2. Extraction tools: Binwalk (for firmware blobs), dd + carve scripts, or custom Python scripts to slice out and decode the data.

  3. Iterative RE: Load the blob into a separate analysis session once you suspect it’s a standalone executable or archive—treat it as its own binary.