-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Its bit hard than you think and may be a resource intensive! #26
Comments
@manan-desai Hello there, i don't have much experience in coding and stuff, but I came across this RNG vulnerability which caught my attention, This was because i have a lost wallet holding some amount of btc, I also came across ur profile and saw the script u wrote, I am currently testing it! Can you help me in this?? I also have some info that u may like to know / can help in this thing ( i found digging the internet ) !! Thank you!! |
Hi, as I mentioned, it depends in which circumstances private key was created and still requires huge space to look. But with some more information it can be possible but no guarantees . https://github.com/manan-desai/mimic-bitcoinjslib-randstorm Also, the above script I wrote for just education. It’s not fast enough to search quickly. I have created this private email to communicate it privately goal-maximum-5i@icloud.com |
I guessed that it that it may be very hard for it to work, but it may worth the try ?? I contacted you on the email you provided :) |
There are a few things I would like to mention.
Brute-forcing this is similar to brute-forcing all possible keys, regardless of whether you consider the timestamp or not. you might need much more information then timestamp!
If you believe the timestamp is a critical factor, you might be mistaken. The process performs an XOR operation on a randomly generated number before the seedInt call. Additionally, seedInt is called twice: first, when the browser window loads, and second, 1–2 minutes later when the user clicks the "Generate Wallet" button.
On this 256-byte array, it performs an ArcFour operation. When the user clicks a second time, it does not reseed with random values; instead, it calls arcFour.next, which flips bits again.
The only potential vulnerability was with Math.random() due to performance considerations. Math.random() was poorly designed, and because of navigator.appVersion < "5", it always fell back to Math.random() in most of browser.
However, given the above, it is still incredibly difficult to determine:
Most Math.random() algorithms had a repetitive nature within the 32-bit space, but it remains challenging to gather all the necessary information.
You also mentioned some methods to generate the next number for Node.js random functions. However, this vulnerability predates 2014, making it irrelevant because, before 2014, V8 and other engines used different algorithms instead of Xorshift. For example, V8 might have used MWC, while others may have used LCG.
Good luck with your search! I’ve already spent two days on this. 🙂
I even created code to mimic old browser random generation after some research (which might be useful) and attempted to brute-force using the bitcoinjs library implementation. However, due to the extensive number of loops, the attempts were too slow.
IMO: I don't think it's worth trying unless you have some of the information I mentioned.
The text was updated successfully, but these errors were encountered: