Hi,

Would like some guidance on what to do when SICE doesn't take you near the routine you're trying to find.

The prog uses two files, License.txt and Licensekey.txt

First time in the prog checks for License.txt and if missing prompts for name + serial

BPX on messageboxa bring up sice, couple of F11 take me back to the code.
Problem is that the code does loads of writing to license.txt inbetween sending the messagebox and checking the serial so the serial checking routine is nowhere to be seen...

Tryed with Olly and found likely locations for the stored serial (i.e. my dummy) and found routines for checking valid chars of the serial etc but no compares with a valid serial....

Have tried the backdoor and found the compare that writes the Licensekey.txt file but then the prog crashes because the file string isn't valid...

Any hints on how to proceed with this type of protection.

Thanks,

medic

You may want too trace into some of the routines that occur between the first time that a file access API call is made to the time the message box with the "bad boy" message is displayed. Making the assumption that you will always be able to fish the full and correct serial out of memory in clear text will cause you nothing but heartache my friend. Very often the correct serial is taken and then hashed into an unrecognizable form and then the information you entered is hashed in a similar manner and then the two hashes are compared to see if they correspond. This way the protection prevents the possibility of "sniffing" out a correct serial in no time flat by isolating the point where a clear-text comparison of the actual and user-supplied serial is made. Look deeper. You've identified this as a keyfile protection of some kind. Take a look at the code where the keyfile is being READ. Examining the keyfile when it is being written may be too late in the game already. Maybe you should consider breaking on a file access API instead of breaking on MessageBoxA and backtracing. Feed it a phony keyfile filled with a readily recognizable character sequence see what is being done to them by the protection. There will likely be length checks, RORs, XORs, SHLs, etc... that result in the keyfile contents being transformed into some kind of "checksum" (not always, but this is the general pattern for relatively simple keyfile protections -though that might be too much of a generalization...meh) Examining the executable under controlled conditions will give you a better idea of what's going down.

Good luck.

Thanks br00t_4_c,

You are right, serial sniffing has cost me days of headaches in the code woods. I had a look at the tut for key files in the mini project area and got some more tricks from there.

I've had a play with breaking on FileRead API calls and it turns out that the prog reads the License.text twice, then reads the LicenseKey.text twice. I think this is for reading lines one and two from each file. Filemon confirms this.

Anyway after reading the LicenseKey.text it loads the contents into mem and then goes off doing other things... no obvious encryption going on..

So my question. Would you spend more time tracing to find what happens to the serial you enter (a valid one create the LicenseKey.text) or would you reverse the LicenseKey.text using API read calls?

Just wanted to know if there was a general order of how to go about this?

Many thanks, am learning fast because of the help and tuts on the forum.

Medic.

Hey Medic,

First of all I would caution that there's no generalized formula, it may indeed be equally productive to go either way. Although I will say that it may be more productive to take a look at what is being done with the contents of the key files (rather than what you have entered) because if the contents are taken, manipulated and then compared to something later on at least you will be able to recognize them if they are in some altered form. From what you have said, I gather the contents of the file are read into a buffer and then basically ignored for a period of time. Well, you might want to set a breakpoint on access of the memory where the file contents are stored. Sometimes protections can be "spread" throughout the application to make it harder for reversers to isolate the "meat" of the protection (security through obscurity essentially, a patient person will eventually piece everything back together in its' correct sequence ). Finding out when the stuff taken from the file is "touched" again will probably give you an idea of when you have gotten back into code related to the protection... vague, but I hope it helps