Re: decrypting bgt stuff?
@8 and 9, this is definitely untrue.
8: cryptographic keys are stored in the compiled bytecode of the executable, not in the encrypted pack file. If the keys were stored in the pack file, decryption would not be possible without opening the file, figuring out the key offset and reading from there.
9: Just because someone knows what algorithm to use for cryptography does in no way mean that cryptography is bad. It does in no way mean that an attacker can easily extract the key from the code of the application. Every good cryptography library has special functions that are used to securely generate, store, utilize, and wipe memory. The only reason people are able to extract keys from BGT so easily is because of one major problem with the way BGT works: the base address is always the same. There is no use of ASLR involved. Since ASLR is not used, it is ridiculously easy to figure out just where each function offset is and put a BP on it. If ASLR were used this would be far more difficult, as even disassemblers would not yield results that could be trusted. I also find it very hard to believe that you have written a program in BGT that is capable of figuring out the cryptographic key used to encrypt data without some kind of disassembler involved. That kind of technology is far beyond BGT's capabilities. Here's my reason why I doubt you: whenever a byte is added to a sequence of bytes, the amount of possible byte sequences grows exponentially. As an example, let's go with the ASCII table since that will be easy to understand. The ASCII has 128 characters, the NULL byte included. For this example, we won't assume that the NULL byte means the end of a character sequence as it does in C, because we don't know if Phillip may have found a way around that. Let's say your sequence of bytes currently is of size 1. That's 128 possibilities. Not hard to iterate through, eh? Let's add some bytes and I shall demonstrate the exponential growth:
2 bytes: 256-16,384 possibilities
3 bytes: 384-2,097,152 possibilities
18 bytes: 2,304-85 undecillion possibilities
Now, lets bring in the Python unicode table (0x0-0x110000). Now we start to get ridiculously large amounts of possibilities. For one byte of an unicode string we have 1,114,112 possibilities right there. Make that sequence 32 bytes long and you've got yourself approximately between 35,651,584 to over 3.1748503857632414... × 10^193 possibilities.
Granted, hackers do not guess keys like this -- the time, as you can see, would be astronomically unfeasible. However, hackers usually have debuggers, hex editors and other tools available to them to aid in the task of breaking encryption. BGT does not however provide such tools. I am perhaps over-complicating the problem, but unless you can provide proof to back up your claim, I certainly will not take you seriously. I doubt that if I gave you a pack file encrypted with a 1024-byte key your little program could crack it in a few minutes.
As for the pack file thing, yes, the pack file has a "known" header. However, remember that its possible to add encrypted sounds to pack files and then decrypt them when you need them and still include them in an executable.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
