Can any one either help me out or point me in the right direction of a good tut.
I am trying to crack a program that uses a time trial which expires at a specific date, using win32dasm. The program warns you that it will expire when 3, 2 and 1 day(s) are left.
I would be very greatful if someone could show me what to look for.

Thanks for your time

Daveb

If it's not packed, it may be quite easy to patch it to remove the time limit. Just try "BPX GetLocalTime" in SoftICE or search the "expired" etc. in the string references of W32Dasm, you will find some clues.

If it's packed, you can try either a loader or unpacking_and_patching it.

Furthermore, if it can be registered, try to find the serial or make a valid keyfile to remove the time limit.

You want to use dead listing first, Windasm, and that is a valid approach.

Search the dissassembled listing for date reated APIs getsystemtime, getlocaltime. Also zero on API that do time conversions. You will find a comprehensive list in here: h**p://www.vbapi.com/ref/f/filetime.html. This may show you potential areas for further analysis.

It is doubtful that the D-day date is hardcoded in the program, but it may not be twist-encoded. Look up the typical date storing formats of windows. I have found a number of programs that encode dates as " The number of seconds since january 1 1980 at 00:00:00" I think visual C programs use that method. translate the date of program demise into such formats and look for a hardcoded Hex number similar to it in the code and data of the dissasembled program.

Try your luck looking for the warning messages. The date handling routine should in some way call the display of these messages, if they are explicitly available in the file.

Lastly, deadlisting approach may be inpractical or unecessarily difficult. Fire SoftIce.

Thanks for the reply, I have found out that the program is getting the date from my satelite, as the program uses my Satelite DVB card to get the correct date. The expiry date is also updated via the DVB card via satelite. The only advantage I have is I have a copy of the program before and after it was updated, do you know of any programs that will compare the code of to .exe files, the files are not protected in any way.

Thanks again

Daveb

read my Guide :-)

This Shareware utility, h**p://www.hexworkshop.com can compare two hex files. It is not the only app, and perhaps not the best, but it may help you.

I doubt that the application stores the date inside the .exe file. An .exe file that modifies itself on disk is quite cumbersome to implement. I would bet the program writes the expiry date in one or several files and or the registry. If you could track down where the date is stored, you may try to find the code that reads the date and process it.
If the program obtains the date from an external source, i.e. the DVB card, I doubt the Windows API are going to be helpful. Try to locate the code that display the message: "2 days left" and backtrace from there. Somehow the code has to know the current date, and the expiration date and has to compare and substract one from the other before displaying such message. Hope this helps.

Thanks for the reply, I have back-tracked from the expiry message and it seems to keep refering back to kernel32.dll is this a likely place to store expiry info. The only thing is the expiry information is sent by satelite and I have a copy of kernel32.dll before and after the the expiry information was sent and I can't find any differences.

Thanks

Daveb

You wouldn't normally store information in kernel32.dll. One of the reasons being that the file is in constant use by the system, so you can't really write to it. Other than that, writing to kernel32.dll risks fucking up the whole system. In short, they're most likely not hiding any information in kernel32.dll

Fake

Thankyou everyone for your help, I have finally tracked down the information, it was stored in the registry, does anyone have any idea how to interpret the data in the registry.

Thanks

daveb

Damn hard to say anything, if you don't give us something to go on. The program could keep the value in the registry as a compare value, and the read it at program startup to check against the system time. This would be the easiest. As to interpret the data in the registry, well if it's not obvious, then track the check in the program down, and find the compare (or whatever).

Fake

The kernel32 reference is just to check the current date and not the expiry date. Check with softice as to where it compares the date.



Boonlia

Just mail me at prince@bppl.net.in and i will send you the complete litrature regarding registry