From: "Ben Davis" Newsgroups: comp.os.msdos.djgpp Subject: Re: Problem with FSEXT Date: Sun, 26 Mar 2000 01:34:54 -0000 Organization: Customer of Planet Online Lines: 46 Message-ID: <8bkkp3$flt$1@newsg1.svr.pol.co.uk> References: <8bht85$61a$1 AT news7 DOT svr DOT pol DOT co DOT uk> NNTP-Posting-Host: modem-33.coumadin.dialup.pol.co.uk X-Trace: newsg1.svr.pol.co.uk 954062435 16061 62.136.86.161 (26 Mar 2000 09:20:35 GMT) NNTP-Posting-Date: 26 Mar 2000 09:20:35 GMT X-Complaints-To: abuse AT theplanet DOT net X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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