AZImmortal wrote:Reality (the user who has been replying to this thread so far) already gave an optimistic example that it would take 120,989 years to crack 184 bit encryption, so if we take 1% of that, it would be 1,210 years, and this is only with 184 bit. You still need to double the time with each incremental bit.
I've actually only quoted time for 114-bit encryption. We're not even half way. If I was quote 184-bit encryption, then 128 bit encryption would be feasibly cracked in a life time. Which its not either. Your point's still valid, though.
webdude12 wrote:I think you missed my point of how we brute forced and that where I did say we got lucky. The idea is not to start a 0 and count up, but in turn methodically randomly pick key and try them. After a key has been test and fails, randomly pick another one.
Not saying it would get the key, but saying that people play the lottery every day with random numbers and every once in a while some one win a million dollars. I personally have 4 computers at home that are on 24 hours a day, but used maybe 10 tops. So if I can make them process some tests with the off chance I might hit the lottery then why not.
That's my whole point. But without having the formula to test generated keys aganist, I can't even play.
I think you missed my point, where math.
webdude12 wrote:You guys seem to think that I am 100% thinking this will get us the key. Im am on your side as far as the chances of getting the key are next to impossible. My whole point of this, was the same as when we cracked the 64bit key with the other group.
1. Brute forcing the key starting at 0 and going up would never happen.
2. The chances of us finding the key using a random key selected from a database are slim to none. But we as a small group have exhausted all our other knowledge on how to get past the security on the device and we had computers sitting idle for several hours a day, why not attempt it.
Like I said at around a 100 keys a second, with 20 of us, we got lucky. Damn Lucky. I know that. Yes we are dealing with a longer key (much longer), but in turn we can also process a lot more keys per second. Billions per second if we use the gpu. Does that really increase our odds any. No. Not at all. But again, while we are waiting for the others to security hole in the software, what would hurt if a few of us let our computers do some work while idle?
My idea is to just give the computer the best chance at finding the key, even though its a near impossibility.
I will be the first to admit. I know absolutely zero about android, the bootloader, etc. And dont really have the time to research it long enough to even start to look for security flaws. I came from a hobby where we beat the hell (Glitched) out of the processor to give up its secret. Without unmounting the chip from the board, thats not really an option here. But even then, after we had the raw code, its was all pure assembly language.
What I do know is most of the web based languages and some C+ / C# / ASM. So even if I do find the key, I am not going to know what to do with it. But why the "Experts" are hunting down security flaws, why not let me others play. Its not going to hurt you. If you do not want to participate dont. I will release the code if and when its ever written so anyone can run it, but its not like I am saying if you do not run this, I am going to shoot your dog.
Look in to setting up mass scale automated software testing. Send crash reports to people who know what to do. Or learn more and find bugs.