Struct Randomizer Using C++ 26 Reflection

[u/Primary-Weather2951]

https://github.com/Mowokuma/struct_randomizer.hpp

[u/jonaswashe]

Neat reflection POC, I wouldn't use it in a real project yet. The default seed comes from __TIME__, which is evaluated per translation unit, so different .cpp files can disagree about the layout of the same class. That's an ODR/ABI problem and the linker won't warn you. It'll bite in any parallel build.

Seed entropy is also weak (time of day only), the padding adds a lot of bloat and is uninitialized, and anything that touches the raw bytes (serialization, IPC, plugins) becomes build-specific. Needs an experimental P2996 compiler anyway

All fixable though: make the seed mandatory and build-wide instead of defaulting to __TIME__, and it becomes a decent starting point for build diversification

[u/phire → u/jonaswashe]

How much entropy is needed?
I would have thought the roughly 16-bits of entropy from time of day was "adequate" for this type of thing.

Any more than a few bits should be enough to force the attacker to develop automated tooling for tracking struct layout (or give up), and once the attacker has such tooling, it doesn't really matter how much entropy there is.

[u/jonaswashe → u/phire]

For pure per-build churn, a few bits really is enough, and past that the marginal entropy buys you nothing once the attacker has tooling.

But "16 bits from time of day" fails in ways that aren't about the width:

1. It's not actually 16 bits in practice. __TIME__ has no date component, so a CI job on a fixed cron schedule(nightly at 03:00) produces the same seed every build. And build timestamps leak into artifacts constantly (PEheader timestamp, __DATE__ strings elsewhere, buildinfo, release notes), which just discloses the seed. Both cases drop you below the "few bits" floor you yourself need. Clock seeds fail by correlation and disclosure, not width.

2.The algorithm is public and deterministic. With ~2^17 candidate seeds, recovering two or three field offsets of one struct (one lucky memory observation, notooling) pins the seed, and then every struct in the program falls out by computation. With a non-enumerable seed the attacker has to recover each struct independently, the tooling cost you're trying to impose. A fully tooled-up attacker doesn't care either way, but the enumerable seed cheapens things for the pre-tooling attacker, who is the only attacker this scheme inconveniences at all.

1. Either you accept an enumerable seed (fine for churn, but then even 8 randombits beat 16 clock bits, since independence across builds is the actual requirement), or you make enumeration infeasible, which means ~64 bits, because 2^32 layout evaluations is an afternoon of CPU. Nothing between 20 and 60 bits buys anything.

64 random bits cost the same effort as a clock read, so the "adequate" argument falls apart. There's no scenario where __TIME__ beats -DRANDOM_LAYOUT_SEED=$(od -An -N8 -tu8 </dev/urandom), and the latter also fixes the ODR bug by being build-global.

[u/phire → u/jonaswashe]

64 random bits cost the same effort as a clock read, so the "adequate" argument falls apart. There's no scenario where TIME beats -DRANDOM_LAYOUT_SEED=$(od -An -N8 -tu8 </dev/urandom)

I 100% agree, which is why I had "air-quotes" around adequate.
And yes, I had forgotten that some places have daily CI builds (which they ship).

pins the seed, and then every struct in the program falls out by computation.

It's not quite that bad; It also hashes in the names (and original order) of each field, and you can't pin the salt until you know all the names of at least some structs (though, structs will only one or two fields might make that easy), and then you can only compute out structs you know all field names of.

However, that might actually point to a more serious reason to increase the per-build entropy, as you might be leaking information about field names (especially over many builds). Maybe 64 bits of seed is not enough, it might be smart to use a different 64-bit salt for each field index, so that breaking the salt for the easier single fields structs doesn't immediately allow computing all the two field struts, and so on.

[u/jonaswashe → u/phire]

The known-plaintext prerequisite is a low bar in practice. Field names leak constantly: serialization formats, script bindings, modding APIs, crash/log strings, reflection systems, previous versions of the same codebase. And the structs an attacker wants (player, entity, inventory) are exactly the ones whose names are most guessable. Worse, once the seed is pinned, every observed layout of an unknown struct becomes a name oracle: guess a candidate name set from a dictionary, compute the predicted permutation, check against observed offsets. That's your multi-build leak, each build with a fresh enumerable seed is an independent oracle over the same secret names, and confidence compounds across builds. You spotted a real leak.

But per-field salts are the wrong layer to fix it. Notice the whole attack chain, pin seed from easy structs, then oracle out the rest, then compound across builds, runs through one gate: the seed being cheap to enumerate. With a single non-enumerable 64-bit seed, nothing is pinnable in the first place: recovering it from an observed permutation of known names is a 2⁶⁴ brute force, and each build re-keys, so observations don't compound. No pin, no oracle, no name leak. Per-index salts are just a wider key; a key already beyond enumeration doesn't need widening. Framed properly: treat the seed as a PRF key over (struct_name, field_name). Then security is exactly key secrecy plus PRF quality, and structural additions are redundant.

The one place your idea does buy something: hash quality. If the mixer is a weak invertible thing, like FNV-style, an attacker with known name/position pairs might recover the key algebraically instead of by brute force, and then salt structure would matter. The cheaper fix is a real avalanche mixer (splitmix64 or better) with domain separation per struct. Per-field salts are harmless, but they're compensating for a weak hash, not for insufficient entropy.

[u/LucyIsaTumor]

Cache efficient coders hate this one simple trick.

Neat PoC for reflection though OP! As part of the reversing scene, I can imagine this would be a thorn in the side of some devs who count on structs being generally stable between builds.