Re: decrypting bgt stuff?
Memory dumps of BGT programs normally haven't 500mb. From 100 to 200, in special cases more, but it isn't very frequent.
Also I apologize for my mistake in calculation, in 100000000 bytes there are 99999980 possible 20 byte sequences, not 5000000. Still not much, but if we want to be exact, it's good to claim.
Also about the example sequence, one byte is enough to call password not printable, if we are supposing the password has been written on the keyboard without using characters generation. Or it may be more exact calling it not writable?
Not important anyway.
Your assuming that the key can be easily determined by picking random offsets in the core dump and just scanning from there. Sorry, buddy, not how that works.
Who's talking about picking random offsets? Let's describe the technique by offsets, okay. Then you pick starting offset 0, and increase it by 1 till you don't have enough bytes to get from that position to form a password.
This basically works, it doesn't matter how much you don't want to believe it.
But I know that some people aren't familiar with theoretical proves. Wwhile you can prove this practically yourself just by following what I said, I can save your time by sending you my code and a practical example of program where it works.
There are two versions. One takes a list of strings extracted from the memory dump by external program. it is fast, it can find the password in few minutes.
Secondone works directly with memory dump and doesn't use any filtering, trying every possible sequence in given range. How fast it finds the password depends on your initial setup. if password is long enough, it will take more than few minutes, but it will find it.
Which version would you like to try out?
Best regards
Rastislav
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
