Re: decrypting bgt stuff?
Hi,
that's exactly why I marked BGT security as very vulnerable. To be able to decrypt german messages during world war II, allies needed to have working enigma machine first, so they could make a decryption machine based on it.
In BGT, you have everything to find out, if any key you are able to think out is correct or not.
And you have a dump file, which as you know contains the key, what is one continuous sequence of bytes.
And you know that it will probably contain upto 20 characters, possibly more like in case of Redspot.
So, how many continuous 20 bytes sequences can you get out of 100000000 bytes long dump file?
Yes, it's 5000000 possible sequences.
It may look many for a human, but this is actually nothing for a computer. Fast C++ program would do this in few seconds.
Another good thing is, that passwords with more characters have longer sequences, so there is even lower amount of possible passwords.
But BGT is generally very slow when you want to perform many operations involving use of strings. Searching the key in this way can take hours, if it's long enough. Of course, even hours is perfectly short time, when we want to decrypt something. But now, it's far from our C++ ideal right?
So, how to speed this up?
One approach is through a basic question. Why the decryption takes so much time?
Answer: because it's trying many sequences, which are obviously not our password.
For example, ascii values 1, 205, 51, 105 are even not printable, so it probably isn't what we want.
Of course, this isn't an absolute claim. If one uses password generator, it can involve such characters as well. It is rather psychological assumption. Why would one use a password generator, if he / she can easily write a password to quotes and it will work?
Based on this conclusion, we can easyly reduce size of the memory dump by filtering out all non-printable characters. We can go even deeper and start thinking, what characters has programmer probably used based on his language.
First option we have is to get all groups of printable characters out of the file and try, if our password wasn't surrounded by non printable characters. Because BGT has functions to get ascii code of a byte, it is capable of doing such filtering. or you can do some preprocessing on the file, there are programs to extract string out of binary files.
This method worked for all BGT games I have cracked, except myone.
If this don't work, then the password is probably surrounded by other printable characters.
So you can connect everything together and search with sequences selecting method.
If this doesn't work as well, then a password generator was probably used and thus you need to iterate through all bytes.
Length of this operation depends on the length of used password. From encryptions I broke, this is very unpredictable. For example, Samtupy used about 170 characters long password to protect sounds of Redspot, but only 4 characters longone to protect sounds of Sammycenter.
I saw games using about 10 character long password, few using 60 characters, so there are various approaches.
But they are crackable in general, and the most easy way is through the encryption tool, through BGT.
If you don't believe, try it out. it is that easy like this.
I personally have also nothing against publishing my source code here, but I think some people won't agree with that. It is bit embarrassing for me revealing it here as some super secret, when it is just a set of ideas, which you probably would invent easily yourself as well if you think about it a bit. But here it is, you have everything to successfully recover passwords of sounds from the most of BGT games. Trivial approach when compared to debuggers, disassemblers and so on, but it basically works and requires less technical skills and time.
For developers, as I said, there are ways to go around this. Not all of BGT games are crackable in this way, one of them is STW and I still don't know why.
I would like to see its password to check, what happened in memory so my program isn't able to detect it. One my theory is, that Samtupy loaded everything to memory first and then erased the password, but I can't think out the reason why he would to do so.
But that's not important anyway. There are more important and more enjoyable parts of coding, which are more worth of your attention.
Best regards
Rastislav
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
