Endianness converter and byte swapper

x86 and ARM are little-endian: the address 0xdeadbeef sits in memory as ef be ad de. Network protocols are big-endian. Every exploit that writes an address into a payload crosses that boundary, and a payload that jumps somewhere absurd is usually a byte-order mistake rather than a wrong address.

The reason this causes so much trouble is that a byte-order error is not a crash, it is a plausible-looking wrong answer. Reversed bytes still form a valid number and a valid-looking address, so the payload is accepted and simply does the wrong thing - which sends you hunting for a logic bug that was never there.

Where it bites

• Addresses in payloads - little-endian, always, on x86 and ARM.
• Values read out of a packet capture - big-endian, because the protocols say so.
• File format fields - depends on the format. PNG is big-endian, ZIP is little-endian, and the same file can contain both.
• Leaked pointers - a leak printed as text may already be in reading order or may be raw bytes; check which before you swap.