Log in

View Full Version : Cracking a trial - Time Up dialog text is not in stringdata


nog_lorp
April 2nd, 2005, 14:33
I am trying to crack a TimeTrial. I have removed CRC and several other checks, and it is now functional so long as I move my clock back.

When the time runs out, I get the message "The time limit for this evaluation has expired.", followed by another message (too app-specific to post).

I have searched quite a bit, and W32DASM does not show this text in any of the References, or anywhere in the disassembly. But when simply open the dll with notepad, and search, it is there. According to "ResEdit", it is in RC Data, 1000(1033).

Any information about how to find references to this would be great.

Thanks,
~nog_lorp
( )

dmx
April 2nd, 2005, 16:13
Think more...what code can be used for generate this window? what function can get SystemTime for example?

Admiral
April 2nd, 2005, 17:53
If you can get the target exe to run when you set the clock back, try to create logs of both successful and unsuccessful exectutions & compare them. I like to use SmartCheck for this:

Tell SmartCheck (if you have it) to log all API calls & run until the app complains about your registration, stop logging and keep the window up. Open up a new instance of SmartCheck and do the same with your clock set backwards. Now it's a matter of comparing the API-call logs to find the point where the results differ (you may want to Page-Down it if the logs are short, or perhaps code a binary comparer if the exported dumps are unworkable). Once you've found the point where they branch, I'm sure you can use your experience to find a decent point to break in order to find where the check is made. Chances are that it'll be near a call like GetSystemTime or FileTimeToSystemTime.

If you don't have Smartcheck, you could effectively do the same thing using OllyDebug's 'Run Trace' (although I find this tends to be somewhat more time-consuming). Obviously, depending on where the check takes place, this can take a very long time to trace.

Of course, this solution is only necessary if the obvious efforts like BPX on GetSystemTime and similars don't help you.

nog_lorp
April 2nd, 2005, 21:15
Thanks for the help.

I have tried bp'ing MessageBoxA, and the program would break immediatley before the nag appeared, but I did not manage to figure out how to stop that.

I did not think of trying GetSytemTime, but I have looked at the several GetSystemTime and GetLocalTime references (in W32DASM), and haven't (I don't think...) found it.

I did not consider trying FileTimeToSystemTime, how would the program use this (so I can see it's the right reference)?

Also, would it be possible for you to point me in the direction of SmartCheck?
(EDIT: nevermind, I think Im on track to finding it. NuMega SmartCheck, right?)

Thanks again,
~nog_lorp
( )

Hero
April 3rd, 2005, 03:09
Hi
a sugestion for finding what is the api function that checks time,or making that message:
Simply get a program named APISpy.Using this program,you can run your program
and log all api function calls.Then easily see that log and you will find the function
that makes that message or read time.

sincerely yours

naides
April 3rd, 2005, 07:30
Quote:
[Originally Posted by nog_lorp]
I have tried bp'ing MessageBoxA, and the program would break immediatley before the nag appeared, but I did not manage to figure out how to stop that.

When the debugger breaks, you are deep into one of the system's dll. you need to trace until the messagebox appears, click the ok button and then keep tracing until you go back to you application code. Then note the instruction that generated the code, and who decides to run that instruction.

I did not think of trying GetSytemTime, but I have looked at the several GetSystemTime and GetLocalTime references (in W32DASM), and haven't (I don't think...) found it.
You need to do live debugging, to locate the GetSystemTime assiciated with your NAG screen

I did not consider trying FileTimeToSystemTime, how would the program use this (so I can see it's the right reference)? Look at the import function list in the Wdasm or IDA listing and you will have list of the time API that the program calls


Also, would it be possible for you to point me in the direction of SmartCheck?
(EDIT: nevermind, I think Im on track to finding it. NuMega SmartCheck, right?)

Thanks again,
~nog_lorp
( )


OK

TBone
April 3rd, 2005, 20:58
You can also try to work your way back up from the failure message instead of trying to break just before it. Start the program with olly and run until you get to the failure message. Pause the debugger and look at the stack window. Follow the stack frames back until you see a return to the program's module (user code). You may have to work back this way several levels until you get to the top of the registration checking code (or whatever it is). Of course, this won't work if the code has deliberately messed with the stack to hide its tracks (ex. returning to a different section of code than where it called from), but most of the time, it's pretty straight forward.

Once you find the start of the checking code, just set a breakpoint on it and unpause the program. Exit the program and then restart it in the debugger. Olly remembers where you set breakpoints, so you'll be ready to drop straight in.

nog_lorp
April 4th, 2005, 21:04
Hmm, don't see any API calls that would create a window (in the trace).

Anyways, how would I go about finding refrences to certain data sections? The time-up message is in the .rsrc section, and is not shown as a Reference in OllyDBG or W32DASM.

Hero
April 4th, 2005, 23:35
Hi
If the message string is directly in resources (rsrc section),noramlly it loads with
"LoadString" api function,But if all the dialog that contains messge is in resouces
normal function that will be used is "DialogBox" or "DialogBoxParam".

sincerely yours

r99
April 5th, 2005, 01:55
load dll in Pexplorer and then search your string in resources
This string must have some ID (= 128 for example)
after that load your exe in Hiew and search binary string 688000
(push 80)
80h=128

Aimless
April 5th, 2005, 06:21
Hullo,

I am assuming you understand that w32DASM does not read Unicode data. And if it does via the patches and addins, it does so quite shoddily.

A general idea in this case is to use a good text/hex editor like ultraedit and search the entire directory for the message. Once normally, and other with unicode box checked.

Note that it is NOT necessary that you will find the exe/dll/etc in the program directory. It could be in windows, it could be in System32 it could, frankly, be anywhere it pleased.

Also, if the strings are PACKED (yeh! only string packing is possible too) or its alternative FUNCTIONS have been used to create the string dynamically during runtime, you will also not find it.

As always, its a good idea in these cases to breakpoint on the nag. If its a messagebox its easy to find the push which points to the address. Rest is easy to find out from the query option in softice. Alternatively, if its a dialogbox or any of its variants, you may have to search a couple of pushes to find out the right one.

Either way, its a good idea to move to IDA. Its free and its good.

Have Phun,

Silver
April 5th, 2005, 11:16
I've found this to be useful:

http://www.analogx.com/contents/download/program/textscan.htm

nog_lorp
April 9th, 2005, 16:13
Hmm, analogX was helpful for finding the offset, I'll try the suggestion of searching for the Resource next.

Update: I found the offset of the string, and am now looking in to references to it (there seem to be several junk references).