Mail Archives: djgpp/2000/03/26/06:50:14
Just to say ... problem solved ... sort of ...
The file used to be 8001 bytes long, ages ago (before it was encrypted). My
last modification to the levels enabled them to be compressed further, to
7990 bytes. So it should only ever have been 7990 bytes long. However it was
not being truncated (I'm not sure why). That explains why I thought the last
11 bytes were not encrypted; they were the remains of an old version of the
file! (As a matter of fact they WERE encrypted, but I was comparing the file
against a decrypted copy of the file with THE SAME remains at the end ?!
Make head or tail of that :-)
The checksum was affected because it was calculated using the actual length
of the file, which was 8001.
The levels were NOT affected because once the game had read the levels (7990
bytes), it assumed it had reached the end of the file, and closed it. The
last 11 bytes were ignored.
First I altered my program to delete the file whenever it was about to
rewrite it. Then I found it wasn't encrypting the file at all. My function
had not installed itself for the new file, because it was not handling the
__FSEXT_creat case (I re-read the docs). I am now doing this, and as a
result the whole thing has suddenly started working; same checksum every
time. I can easily generate new copies of the game with different encryption
keys, and release them, as often as I like. Beat that! (though someone
probably will...)
So, Damian, you can find brute-force-style the encryption key of one copy,
but it won't be very useful when I release the next version! And is it
really worth it, for the small price I'm charging for the game? (I'll tell
you what the website is as soon as the website exists.)
One thing I still don't understand: if I don't delete the file first, how
come it doesn't get truncated? The O_TRUNC flag has been specified in the
FILE_CREATE() macro (see my first e-mail), and the _open() and _creat()
functions ultimately receive the same attributes they would receive
normally! Someone tell me if I missed something.
I am not really worried about this, because I am not distributing the
encryption code; just the decryption, so the user's computer only ever needs
to read the file. I said before, why write when one will read! :-) Try
saying that 10 times fast.
Ben Davis
- Raw text -