Hi guys,

I've recently been trying to crack Cool Edit Pro. Upon attempting patch the program, I get a "file integrity compromised" message. This let me know that there is probably a CRC check. I've done some research / read some tutorials about CRC protections, but the info was somewhat sketchy. I'll tell you what I've tried though and *hopefully* someone will be able to point me in the right direction.

1)The MessageBoxA containing the "file integrity compromised message" was the first and most obvious place to start. This I both examined in Wdasm and traced in SoftIce. There are a couple of jumps which bypass this mbox, but the program becomes frozen upon trying to change them so I concluded that the check must be earlier during the initialization.

2)I examined the program in an API moniter looking for all functions like CreateFileA and _lopen since I know the program will need to open itself to perform the CRC check. There were 2 promising files being opened with the _lopen API. These were coolpro.exe and cool.ini. I was *hoping* that the program was opening itself to perform the check. There was also an interesting reference to a checksum = 832952384 in the .ini file. Once I found this I did a search for it in memory and put bpm on all of the locations from the search. SoftIce broke a couple of times, but the contents of my memory loctions had somehow changed and no longer had the check sum value in them. I can't find any isolated function that looks like a CRC check,
though there is some code that operates on the coolpro.exe file after the_lopen and _hread APIs. This code does not look simple at all to reverse and I'm not even sure it is what I'm looking for !

3) Also, the program behaves somewhat inconsistantly...For example, after tampering with the file I first get a "file integrity compromised message box". A little later the program simply closes without displaying the message box. This continues to occur somewhat randomly and a couple of times the program even ran normally without displaying the message box or closing itself. Could this be indicative of some "self modifying code" ???

I'm a little lost on what to try next and will really appreciate some advice...

It seems like this protection is a little more challenging than newbie level, but I think there is much to learn and I don't want to give up on it ;-)

Thanks in advance...
Clandestiny

CRC calculations are not usually performed on the file contents, instead they are usually performed on the memory contents. To find the code that does a CRC put a breakpoint on a particular byte of code being read. This will probably help you to find out where the CRC code is.

IcyDee

Also true, but you might wanna try to see
if the app uses any kind of memory mapped files.
The obvious reason to use memory mapped files is to transfer info between applications, but i've seen protections that use memory mapped files to check their own integrity.
functions like MapViewOfFile (i think, not sure, been awhile..) and related might be used.
A good tip is to patch the CRC check but in a way that will fool the program. Don't just patch a conditional, try to patch the "correct" checksum transforming it to the checksum that gets calculated after you patched.

LS

Thx guys for the input...

Unfortuntely, this is my *first* attempt at reversing a CRC check and my problem right now is not "how to patch" but "how to find" the CRC check. I looked into Lord Soth's suggestion about the MapViewOfFile function. A really good suggestion I might add (and one which I will keep in mind for future CRC protections), but alas Cool Edit does not seem to use this particular function. I have read several tuts on CRC, most of which suggest the CreateFileA function to be a key indicator of a CRC. CreateFileA is called in this program and I've tried to examine the surrounding code with limited success...if there is a CRC here it does not look to be a simple cmp --> jmp. I'm actually a little lost on what else I should try and I would really appreciate it if a few of the more advanced reversers on the forum could offer me a few more detaitled pointers or possibilites which I might investigate.

Thx in advance,
Clandestiny

hi clandestiny,
i myself don't have that much of experience with crc-secured files, but
maybe a good first step for you to take, could be this:
find out, if it is just a simple crc or a more complicated one. e.g. change
a byte (preferably in a string somewhere in the file), let's say from
'a' to 'b'. run the file, check if it will abort. if so, change another byte
from 'd' to 'c' or whatever. you've got the idea?
if it is just a simple routine, you might success this way..
but it's just a workaround, i know.
if the programmer did a very good job, he didn't set a crc-check across
the whole file, but instead of that just a part of the code, that is important.
i have once come across a prog of that type and so the method
mentioned above didn't lead any further.

maybe i could give you some ideas to think about

be careful

Did you take the few means to check if this
is a memory CRC ?
The first thing to check for is if the program is actually performing the CRC on
the contents of memory.
Place a BPM on the patched bytes for read
access (I'd suggest a byte BP, nothing bigger).
If this is the case, you won't have much
work to do to reach the conditional.

LS

Hello Clandestiny. Instead of boring you with the facts I will let someone else do it ;-). I downloaded most of the DREAD website before the group closed it down and I have two useful essays which were on the site regarding CRC. One is about how the CRC check is calculated and how it can be reversed and the other is an example of how to find and reverse the CRC check on a particular program. All credit to DREAD. I'm sure this will be of use to you! For some reason I can't upload attachments so just e-mail me at lordrhesus@yahoo.co.uk and I will send you the essays.

To Hackscode: You were right about changing a random byte of some string unrelated to the protection. Apparantly (thankfully), this is an *easy* CRC since it must perform the check across the whole file rather than just on the important part of the protection scheme.

To Lord Soth: I think I now understand about what you and IcyDee were saying about the CRC being on the memory contents rather than the file contents and I feel almost *silly* to ask this next question, because I think it must be a painfully obvious one...but I really want to learn and here goes anyway...

To my limited understanding (and please correct me if I'm wrong) the program will use CreateFileA or _lopen API to load the file in memory and return a pointer to the beginning of the file. Then it will have to read either some or all of the file in order to perform the CRC. I changed a single byte in the file as was suggested and I'm now wondering how exactly to locate the address of this specific byte in memory once the file has been loaded so I can bpm on its address? Now I know that Wdasm gives me the offset of each line in the file. Could I just add the address of the file pointer returned by _lopen + the offset in Wdasm to get the memory address to bpm on. Am I on the right track here or completely off target ???

Thanks A Lot,
Clandestiny

Hi Clandestiny

I am trying to make CoolEdit 2000 v1.1 work properly and I found this discussin very interesting. I would like to know how far are you. I am almost sure you are finished now. How about a tutorial?

Met