Understanding GCD Bias on signature generation (Need Technical Expert Assistance

[Rapten]

Okay, how do I even begin, it all started about two months ago when I came across a crypto scam wallet that is connected to a pigbutchering scam that had hundreds of thousands of transactions and I thought wow that seems odd to me there has to be some sort of vulnerability in this wallet that could help rescue these victims from. So I start poking around and it appears that some of its earliest transactions exhibit GCD bias of about 39% back when the random generator for signature was using prng before RFC 6797 was implemented there is a window of about 3000 signatures in this wallet that are all bias'd however besides reuse and several failed lattice attempts later I've hit a brick wall on attempting to break the key for the wallet to try to release all the funds from all the people this wallet has scammed. Its automated runs batched transactions produces thousands of transactions daily and appears to have fixed its initial prng state which is why anyone that pulled up all the transactions for it and tried to build a lattice for the wallet would straight up fail it's been diluted from better rng as time has gone on. For grins I started poking around a few other wallets with a similar mo thousands or hundreds of transactions per day gcd bias in their implementation initially that smooths out over time. I would really love if anyone who understands this stuff and is interested and willing to help me recover the funds for this wallet. we are talking massive money in the neighborhood of hundreds of millions of dollars in these wallets that I truly would love to set back to their original owners. Anyway if anyone understands how the python scep256 libraries changed during 2022 to around July 2022 and has the technical expertise on how to crack this sort of implementation and wants a project I'm sure it would end up with a sizable reward I'm more than willing to share all the knowledge I have on the situation and would love to get an expert opinion on how this stuff works. I set up sage math and have fpylll installed along with all the other dependencies but just honestly don't have a complete grasp how to get this past the finish line. If anyone wants to help I'm sure if we crack this anything any of the victims get back would be a win for them.

[Roberto888]

You're dealing with a classic ECDSA nonce bias attack scenario. The key insight you're missing is that even with later signatures using better RNG, the initial biased signatures still create a solvable hidden number problem.

The attack works like this:
1. Collect all signatures from the biased period
2. Form lattice using the biased nonces (even partial bias helps)
3. Use lattice reduction (LLL) to recover private key

Your main issue is likely in lattice construction. Since the bias isn't present in later signatures, you need to focus only on the ~3000 biased signatures and build your lattice from those. Don't mix in the good RNG signatures.

The bias means: k = k_biased + small, where k_biased is predictable. This creates a solvable system.

If you want to share the transaction data, I can help construct the proper lattice. The money is definitely recoverable with the bias you described.