Hey everyone,
I’m diving into a study on random number generation related to Bitcoin 0.1.5 and Windows XP. It's about how `CryptGenRandom` works in that context:
Windows XP SP3 CryptGenRandom → OpenSSL 0.9.8h → Bitcoin 0.1.5.
Not saying this is a way to attack Bitcoin or get historical keys. Just researching some historical aspects, no intentions of hacking wallets or anything like that.
Exploring Windows XP CryptGenRandom and Bitcoin's Early Days
4 replies 92 views
What’s stopping someone from using WinDbg to trace syscalls in Bitcoin Core on newer Windows versions? Seems like they could snag private keys or even the AES state for wallet passwords.
Honestly, do the devs even use WinDbg? They should really think about blocking it from attaching to the Core.
Hey there,
Good point! But if someone has access to the machine with all those privileges, the game is pretty much over.
WinDbg isn’t a flaw in Bitcoin Core itself. If an attacker can attach a debugger, the security wall is already breached. They could view secrets in memory regardless.
Quick update on the XP SP3 `CryptGenRandom` work.
There are two key components in this RNG process: the transport side and the provider side. The transport side has been tightened up due to several `seed2state` campaigns, which include checks and behaviors related to RC4 and ADVAPI.
The provider side is still being pieced together but isn’t fully complete yet. Just replayed the final `rsaenh` block from captured inputs.
Little update on my XP CryptGenRandom project.
Just rolled out a new replay campaign: `seed2state_v29_g_composed_provider_bridge`. It looks at the provider side with `rsaenh.dll` and checks the RNG relation in a single captured run.
Also, I realized I wasted time looking for an external source due to misreading the disassembly. The `out` argument in the FIPS block wasn’t an upstream source; it was just the local destination buffer. Learning a lot here!