Kayaker
November 28th, 2000, 19:51
Hi All,
Everyone seems to be doing great with this Project and there's some good learning and understanding going on. I'm really pleased. But I don't hear much CRC noise
So...
By now everyone's figured out that the program creates a Happyicon.lic file in the program directory if it's successfully registered (by fair means or foul
If you modify even one byte of the .lic file you get a nice "The lic file has been modified !! 1toX cannot run" message.
Don't worry about the 1toX business, that's actually another program by the author and he obviously didn't change the code to suit HappyIcon...
At its simplest, a CRC (Cyclic Redundancy Code) check, well really just the most basic Checksum I could think of, might be to add all the bytes in a file as hex and compare this value with the one it's *supposed* to be. If they don't match, the file has been altered.
In reality they are much more complicated than this and you could read A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS by Ross N. Williams, somewhere on the Net, as a start.
Often, what will happen is that a program will Read its exe file in as a regular file (since the program is already mapped into memory it can do this), and pass it through some CRC algorithm routine. It might be on the whole file or just parts of it. If you've patched the program it will likely fail the test.
This program does the same thing except that it only reads in the .lic file. If you were to trace the code after the critical regged/not regged jump (this was Task 2d!), or use an API monitor on it now if you've patched the jump so it always produces a .lic file, you'd see that the program goes through 2 sequences to write the file.
First it uses CreateFileA, WriteFile and CloseHandle to write the basic information into the file. It gets the structure of the file from the .exe. If you do a search for say the 1st line, "DO NOT MODIFY" you'd find it hard-coded in the file.
Then it uses CreateFileA and ReadFile to read the file back in, calculates a Checksum, which actually includes the Checksum value itself, closes the file with CloseHandle since it can't be written to if it's previously open, and then writes the Checksum value with WritePrivateProfileStringA.
This should give some indication of how to monitor for the CRC check on program startup.
CreateFileA DO "dd esp->4" will display the name of the file which is to be read in (Happyicon.lic is the one of interest) in the Data window. "dd esp+4" would display the 1st stack parameter, or the pointer to name of the file, "dd esp->4" displays the contents of that address.
ReadFile DO "dd esp->8" will display what has been read into the buffer that receives the data once you've F11 returned.
GetPrivateProfileStringA is used to retrieve the CRC value which was written into the file. The destination buffer for the function is the 4th stack parameter, the sequence being esp + 4, 8, C, 10, 14, 18, 1C...
These 3 Calls should be enough to trace the CRC check to the simple jump which will bypass it and avoid the MessageBoxA (which is another breakpoint you can sometimes make use of).
Finish this part and the Fat Lady can sing... ^_^
Cheers,
Kayaker
Everyone seems to be doing great with this Project and there's some good learning and understanding going on. I'm really pleased. But I don't hear much CRC noise
So...
By now everyone's figured out that the program creates a Happyicon.lic file in the program directory if it's successfully registered (by fair means or foul
If you modify even one byte of the .lic file you get a nice "The lic file has been modified !! 1toX cannot run" message.Don't worry about the 1toX business, that's actually another program by the author and he obviously didn't change the code to suit HappyIcon...
At its simplest, a CRC (Cyclic Redundancy Code) check, well really just the most basic Checksum I could think of, might be to add all the bytes in a file as hex and compare this value with the one it's *supposed* to be. If they don't match, the file has been altered.
In reality they are much more complicated than this and you could read A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS by Ross N. Williams, somewhere on the Net, as a start.
Often, what will happen is that a program will Read its exe file in as a regular file (since the program is already mapped into memory it can do this), and pass it through some CRC algorithm routine. It might be on the whole file or just parts of it. If you've patched the program it will likely fail the test.
This program does the same thing except that it only reads in the .lic file. If you were to trace the code after the critical regged/not regged jump (this was Task 2d!), or use an API monitor on it now if you've patched the jump so it always produces a .lic file, you'd see that the program goes through 2 sequences to write the file.
First it uses CreateFileA, WriteFile and CloseHandle to write the basic information into the file. It gets the structure of the file from the .exe. If you do a search for say the 1st line, "DO NOT MODIFY" you'd find it hard-coded in the file.
Then it uses CreateFileA and ReadFile to read the file back in, calculates a Checksum, which actually includes the Checksum value itself, closes the file with CloseHandle since it can't be written to if it's previously open, and then writes the Checksum value with WritePrivateProfileStringA.
This should give some indication of how to monitor for the CRC check on program startup.
CreateFileA DO "dd esp->4" will display the name of the file which is to be read in (Happyicon.lic is the one of interest) in the Data window. "dd esp+4" would display the 1st stack parameter, or the pointer to name of the file, "dd esp->4" displays the contents of that address.
ReadFile DO "dd esp->8" will display what has been read into the buffer that receives the data once you've F11 returned.
GetPrivateProfileStringA is used to retrieve the CRC value which was written into the file. The destination buffer for the function is the 4th stack parameter, the sequence being esp + 4, 8, C, 10, 14, 18, 1C...
These 3 Calls should be enough to trace the CRC check to the simple jump which will bypass it and avoid the MessageBoxA (which is another breakpoint you can sometimes make use of).
Finish this part and the Fat Lady can sing... ^_^
Cheers,
Kayaker