i'm sorry for asking help in the first post, but i think this code is so advanced for a newbie like me,
i practiced RE in the far days like 1999 but my knowledge is so old for now, it's about 1 week that i'm reading and searching still no success with this one.

Here is the short story
-i have to run the code and wait for 1 hour, a window pops up after about 1 hour and says that i'm phucked with a message about 100 characters about "non genuine piece of hardware bla bla bla..." and i have to push "OK" and everything is gone.
-Also when softice comes up by "bpx CreateWindowExa" i cannot find the message in memory by using 'S' command.
-I tried the tool "PEEK" , but could not find the string in the program too .

Inciteful and helpful post... A complete lack of mind reading ability on my part prevents me from knowing what app you are referring to.

Bob, a couple of ideas here. Since you have SICE running, and triggering on the messagebox, single step it back to the code that CALLED it, and give that a look. It could be a simple branch instruction before the box that needs to be forced, or nop'd.

Also, have you run it through IDA? That's always step #1 for me.

If for any reason you are unable to do either of these steps, let us know why, and maybe we can provide pointers in the appropriate direction.

Yes, but that's exactly what we expect of posters here, to NOT NAME THE TARGET when asking how to crack any commercial app, just as the FAQ asks.

The original poster did a good thing, so...

Logically some sort of timing mechanism is being used, crapping out after ~1hr, so you need to look into ways that could be done. 2 possibilities, though not the only ones:

SetTimer/KillTimer

http://msdn.microsoft.com/en-us/library/ms632592(VS.85).aspx

CreateWaitableTimer/SetWaitableTimer

http://msdn.microsoft.com/en-us/library/ms687012(VS.85).aspx


If you do find say a SetTimer call with a very large timeout value (in ms) equating to about 1hr, you could change the timeout to a shorter value for testing.

Not finding a message in memory means nothing, it could be encrypted until the last moment or be in unicode, which the Softice S command won't find directly, unless you modify the syntax used.

Check the common directory in the Programs directory also check documents and settings "application files" do a search in those using 010 Editor a commercial app with a trial period, (easy to fix). has the best string search capabilities of any app I've found.

SiGiNT

Thanks for ur helps, i really appreciate.
It's a very dangerous software for reversing, that's why i didn't give enough infos.
Running Softice was a headache, but running softice for debugging this software was a real pain in the ass , after Ctrl+D pc got rebooted , but i get ride of it.
As Kayaker said , it use so many SetTimer/KillTimer & CreateWaitableTimer/SetWaitableTimer.
Also there are so many "; dwMilliseconds" in IDA.
Bpx PostMessageA landed so far from where i need so i get lost in the code.
i can see these codes many times, Any idea ?
push eax ; dwMilliseconds
push 7D0h ; dwMilliseconds
push 0FFFFFFFFh ; dwMilliseconds
push 3E8h ; dwMilliseconds
push 3 ; dwMilliseconds
push 0 ; dwMilliseconds

if 7d0h = 2000 ms and 3E8h = 1000ms then what does 0FFFFFFFFh mean !!??

I download SysAnalyzer from RCE tools and when it analyze the process it can find the message i was looking for, but i dunno how to find it in .exe or the address of it in .exe file
the report of Sysanalyzer is like this:

RegKeys
-------------------------------
The string i'm looking for........


So i beleive it's in .exe file , i've already checked other files.

In windows all timers have an ID, and when you create, set, reset them, you have to use that ID. When the timer message arrives that triggers the nag, you should be able to get the timer's ID, and use that to filter down all the calls to the timer functions to only the ones that matter.

Then, once you find those, examine the surrounding code, and see if you can see anything that looks suspicious.

If there are only a couple of them, change them 1 at a time, and see if you still get the nag, and when you get that figured out, work backwards to figure out what triggers that section of code.

Looks like the author of the program really read F+'s (bless his soul) how to protect better...

A simple idea can help here.

It does not matter how many timers are used, or where they are used, or whether there is really no timer, but the author simply introduced loops which he counted with a stopwatch and hence it take an hour for the nag to show. What matters is that the binary cannot be suspended while an hour passes.

That means, some code is getting executed. Again and again and again and again... for 1 hour. AFTER which the nag pops up.

So, your best bet is to use a good debugger (IDA debugger does the trick) and "TRACE OVER FUNCTION". The idea is this:

1. You run the exe in IDA with TRACE OVER FUNCTION mode.
2. Some functions return back, others will wait for an hour. Terminate once you think its moving towards the hour function. Terminate the process (kill it) if you think its gone into that 1 hour mode (but good thing now -- you know that LAST function you TRACED OVER which triggered this)
3. For EACH function that it takes more than an hour (which you have been judiciously terminating because you want to go deeper and see what sub-functions it calls and then down again), re-run the exe and this time RUN TO CURSOR upto the function that you last saw starting that long 1 hour process. Then, when your RUN TO CURSOR hits, use TRACE INTO FUNCTION and get inside that function. Run the TRACE OVER FUNCTION again, until one of them goes into that long loop again. Terminate it and restart.
4. Within a short span of time you should be able to trace the OFFENDING function that uses an HOUR to pop up a nag (better, the lines that cause it to loop).

As Old Red Cracker used to say: "Most of the time RCE is chasing tentacles..." Long winded process, but one that ALWAYS will draw results instead of using new fangled tools that you DON'T know will work in the first place.

THEN, what you do to break it, is left upto you.

Have Phun

There're a lot of functions which have some kind of timeout, like WaitForMultipleObjects. Another way of measuring one hour would be:
StartTime = GetTickCount(); // at program start
RunTime = GetTickCount() - StartTime; if (RunTime > 3600*1000) ...

You should first check which functions are used (imported or loaded by GetProcAddress) - does the program really call SetTimer / GetTickCount / CreateWaitableTimer? If SetTimer is used, a WM_TIMER message will be send to the application - Spy++ or similar could be used to track that.

radix

Hey Aimless, that is quite a quote, and quite a creative strategy you described here. . .
The epitome of the word: Heuristics!!!!

yea but F+ taught us how to 'searching' too

Anyway, i cannot config Ida & Olly to debug it even with latest tools. This program is using all of the newest anti debugging methods + some CRC32, MD5, compressed data parts
Eliminating the functions was a very good idea,
I found a very usefull Ida plugin from download section "Resolves indirect calls jumps"
It can run (not debug) the program and load all the functions and comment everythings, and i guess it's filling some of parts of the codes ..... and list every function call in Ida indicator window , about 4000 lines for 1 hour till the screen. Now i'm trying to find the the difference of first 60 minutes and last 5 minutes.
The log is like this:



Another problem is that right now in the compressed part of the code i found something about Veri$ign Time Stamping Services , and i see a .cert file too !

Bob it's completely possible that you've run across a target that's above your skill level. It happens to all of us.

Now, I'm not saying that you should STOP, far from it! I just wanted to point out that being stumped happens to all of us from time to time.

I once worked on a generic protection for over a MONTH. But when I was done, I understood it enough to write a ripper that removed it from every target it was installed on from then on.

I cannot solve this so i'm asking help again.
I could find where the nag is creating , and i can stop showing it , but after that the program exits.

Finally after 1 month i could manage it to run the program under Olly & Ida too.
I find a function and there is : cmp esi, 110h
and after 60 minutes ESI==110 and it's called by a AfxWndProc. (so i'm in the middle of window create process)

when softice comesup the call stack is look like this:

706FA5
EndDialog
InsertMenuItemA
7C90EAE3
GetWindowTextLengthW
CreateDialogIndirectParamA
70AFBE
70B1DD
5D0722
SetWinEventHook

It looks like that the thing that cause all the problems, it change the call stack, so by pressing the F11 , i went back to Exit way.

I cann't find a BPX for landing softice closer to the problem to fix it.
Also i have to say it's a self modifying code.

I guess the instruction that is jumping to that "CMP ESI,110h" is kernel User32! "INT 2B" instruction and maybe that's why i cannot trace it back from here.

Ok , well done.
Thanks for the great knowledge & informations and help ...
After 3 weeks , with 2 computers (at the same time) running SoftIce, OllyDbg and IDA ,
i managed to find out and pass the nag.

Here is the long story of my experience if anyone likes to know:
The nag screen was inside of a function that (i dunno why) IDA & Olly cannot analyze it correctly
and don't show it as a function , in the first days i tried to fallow that but i didn't see any XRef
to this function , so i ignored it.
With some luck and help of tools in the download section , i installed the plugin " IDA EXTRA PASS"
and now IDA analyze that part correctly and shows it as a function, but still without any XRef.

In the disassemble list of the program there are some parts which IDA & Olly shows strange data like:


but 1 part is so big about 3000 Bytes , i went into softice and extract the whole part using "U" command , and
save it to text file via SoftIce Symbol Loader.
Then i searched for the address of that function in the text file and it was there and then i replace it with NOP

now i can bypass the nag completely and the the program does not exits BUT after another 30 minutes , it restarts .
Maybe it's better to forget it
cause this software works with specific hardware PCI card (i mentiond in the begining of thread)
and it's really above my knowledge.
but it's not important , cause it looked un-crackable to me , but i did it.

1 more question , is there anyway to import that part from softice dump to ida and force ida to analyze it and makes the XRef and ... ?

Bob, if you know the address in the disassembly where this stuff is, just go there in IDA, and press "C", to tell IDA it's code that it missed. Sometimes when you do that, it'll mysteriously find references and stuff.

So, give THAT a try.

hello this ctrl+D crash is interesting was IceStealth active ?

if that is the case please write me a pm about your finding

ty

This is software for a pc based surveillance system, so it use Directx & Drirect draw Overlay and it's so related to vga card , and i think that was why pc got rebooted everytime i pressed Ctrl+D
So the trick i found was that if i just run the program , the program starts to working in the background but it waits for user&password to login to software.
If i leave it there and don't login to sofdtware , then i can use Ctrl+D without any problem. (Also Driver Studio with latest patch 3.2.1 is so much more stable than older versions for me)
But if i login to software and EVEN logout & exit the software , then Ctrl+D with reboot the computer !


I found a solution to that too but it's not working. In IDA in "Edit->Other->Manual instruction" or pressing "ALT+F2" i can change the disassembled instructions with correct ones but the addressing is not right.
for example in softice it's like this:



but in IDA i cannot fix the addressing and it goes like this:

not even after playing with D & U & C key.

nice info and yes the trick with softice is to make the d3d / opengl window in windowed mode i dont know the exact apis right now but both engines have something to start a d3d / opengl window and you set this to windowed

that happens with all new grafic card to me i also got a other like the "gf mx 420" with 64 mb ram what dont got the crash problem no matter if d3d or opengl is in fullscreen


hehe and nice that the good old softice didnt gave up

about your dump problem maybe you dump the whole executable with iceext dump "!dump \??\c:\mywantedexutable 400000 FFFF"
but the dump of iceext sometimes cause problems aks bsod or sometimes i dont dumps all of the code but its sure worth a try