First, let me say that I have read every piece of elicense information on this board and I am still stuck. And yes I read the FAQ too.

Heres what I did:
I dumped the program after suspending it at the oeip with the a eip, jmp eip method. I then rebuilt the IAT with Import Reconstructor. I start up the fixed file and everything seems to work ok and then bam: access violation at blah blah corrupt program error. I don't think the target is using the xor method like in deep paint 1.1b so I'm pretty sure my dumps are OK. I'm figuring that my problem must be the rebuilt IAT then? Or a problem with the PE header? I am not looking for a simple crack for this I just need some hints to point me in the right direction. I've tried for the past 2 days to get this and I'm not going to give up

A big thanks to all of the cool posters on this board! I have learned a lot already by studying your work.

Even after successful unpacking and IAT reconstruction, the program may have further protection, or other tricks. You need to learn to interpret those access violation report messages and debug the unpacked program, to figure out why and where those errors are generated.

The access violation message/report is FULL of useful information

This is the code that crashes:
:00403210 85C0 test eax, eax
:00403212 7410 je 00403224

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0040321F(C)
|
:00403214 8B00 mov eax, dword ptr [eax] ;First access violation here <--
:00403216 39D0 cmp eax, edx
:00403218 7408 je 00403222
:0040321A 8B40DC mov eax, dword ptr [eax-24]
:0040321D 85C0 test eax, eax
:0040321F 75F3 jne 00403214
:00403221 C3 ret



* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00403218(C)
|
:00403222 B001 mov al, 01

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00403212(C)
|
:00403224 C3 ret
:00403225 8D4000 lea eax, dword ptr [eax+00]


===================================================================

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0054C16E(C)
|
:0054C14E 8BD7 mov edx, edi
:0054C150 8B83D4080800 mov eax, dword ptr [ebx+000808D4]
:0054C156 8B08 mov ecx, dword ptr [eax]
:0054C158 FF5108 call [ecx+08]
:0054C15B 85C0 test eax, eax
:0054C15D 740D je 0054C16C
:0054C15F 8BD0 mov edx, eax
:0054C161 8B8364080000 mov eax, dword ptr [ebx+00000864]
:0054C167 8B08 mov ecx, dword ptr [eax] ;Second violation here <--
:0054C169 FF5110 call [ecx+10]

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0054C15D(C)
|
:0054C16C 47 inc edi
:0054C16D 4E dec esi
:0054C16E 75DE jne 0054C14E

The first violation appears to be an essential part of the code that reads data or something, the second I have no clue...

Let us concentrate on the first Access violation: eax should be holding a vaild address right before the 00403214 mov instruction, but in the unpacked program is not. check out the code above that instruction to find out where eax gets its value. Also, if possible, trace the same code in the packed, original application, to see how this code is supposed to work under the "right" circumstances.

appears to be scanning a linked list for a value equal to the one contained in edx

Firstly, thanks for the help naides! Ok, I tried editing the jump you suggested (I had changed this jump before when looking for myself but forgot) and it makes the program stop working. I edited other jumps in the loop and they make Icons on the map screwy so I think this loop can't really be edited.
I looked at the first violation loop in both the original and dumped programs and they look about the same except some eax values are different (like 130000 in dumped and 180000 in the orig) but I don't think that has anything to do with the problem. The dumped program crashes within 15 seconds of starting it.

Something very interesting: when I have runservice.exe running the program does not crash. Heres the procedure:
1. start orig. program (runservice.exe shows up in task manager)
2. close orig. program (runservice process is still running)
3. start dumped program (runs without crashing)
I can't just start the dumped prog. and then run runservice.exe (it won't stay in memory)

How can I figure out why it doesn't crash when runservice is running? The dumped version does not ask for vtcpak33.dll to run but it does ask for zsapi.dll.

zsapi has functions in it with nice names like: could not read license data, grace period expired, licctrl_ServiceEvent, and many more that I don't like the looks of. I'll try and look with Filemon to see if runservice is doing anything. Maybe the program checks to see if runservice is in memory?
Whatever the problem is runservice has something to do with it.
One step closer.....
Any suggestions would be most helpful
And thanks again naides for taking the time to reply!
Is it just me or has the forum been down for a couple of days?

Well innocent, lets start by saying that you don't look so innocent, you are guilty of cracking, as charged!

The linked list scanning we dealth before may or may not be related to the running of the program, I don't know. The symptom here is that some code, somewhere, needs to be run to:

initialize and load the right "seed" value in eax in the 00403214 scanning loop we discussed before. Linked lists are very sensitive the the initial values. if they are not correctly initialized to a valid chain in the heap memory they sooner or later will end up on a memory address that haphazardly result in a access violation when they point to an invalid memory address.

AND

start the service "runservice.exe" module in the correct fashion so it stays in memory and provide the critical services your app needs to run.

Likely you bypassed the execution of that critical code when you unpacked your app. Perhaps it is run before or during the unpacking. The challenge would be detect such code in the original, unpacked app and emulate it or somehow run it in the unpacked app.

Notice that I DO NOT know the answer to your problem, I just give you pointers of where to search.

Ok I have been trying to trace runservice with softice but haven't had any luck. In order for runservice to be ok I have to open the original program and click free trial. When the orig. prog is loaded it loads runservice at startup. I closed the window with the free trial button and tried the dump. Still crashes. If I open orig. prog and hit free trial then close the orig. and try the dump, it works. This tells me that something is changed in runservice from the time it is loaded and after the orig. prog is loaded. Runservice is a protective measure and is not critical to the program itself; though the dump is still checking for it somehow...

These are the api's used by runservice:
Import Module 001: KERNEL32.dll

Addr:000020DA hint(018F) Name: GetVersionExA
Addr:000020CA hint(01DF) Name: LoadLibraryA
Addr:000020B8 hint(0153) Name: GetProcAddress
Addr:000020A8 hint(012D) Name: GetLastError

Import Module 002: USER32.dll

Addr:000020F8 hint(02B3) Name: wsprintfA

Import Module 003: ADVAPI32.dll

Addr:00002110 hint(0088) Name: DeregisterEventSource
Addr:00002138 hint(01B7) Name: RegisterEventSourceA
Addr:00002128 hint(01C1) Name: ReportEventA

How would the dump access runservice?
However it does it does it continually because if I have runservice running and I close it after i'm in the dump it crashes. So it must be continually checking to see if it is there.

Oh and btw no one is innocent.

OK

1. Ok olly breaks on dll's but does not break when runservice starts (runservice is an exe so it shouldn't break on it anyway right?)

2. runservice is very small and easily disassembled (but not easy for me to understand... I have been looking at the api's in the w32 programmers reference but so far I can't really figure it out I'm not the greatest with complex asm yet) I'll attach a txt with runservice code

3. I can get runservice to break on getprocaddress but can't seem to trace it back to the original call (kept f12ing and setting breakpoints on the calls but I can't find the original call)

4. the bpint 3 method doesn't work

5. the unpacked program crashes at the addresses in my earlier post: the problem is that the routine that produces the violation at 00403214 is called by about 100 different lines of code

6. Did you get my pm? I was hoping to talk to you outside of the forum
I'm trying my best to get this but I'm a newbie so go easy on me

if the program you unpacked ran ok when you fixed the iat .. i don't think the problem remain on IAT ... it most have some other hidden crc checks .. that works using exeptions to crash the app. could be also it stopped decrypting some part of the code as soon it checked it was unpacked.. then when it tries to reach some code can't read/translated it because still is encrypted and that's the reason why crash.

1. I don't think it uses crc checks because the dumped program will run fine if runservice.exe is running
2. The dump is not still encrypted because it runs fine with runservice running.
Somehow the dump is checking for it in memory or maybe runservice is supplying the dump with good values I don't know which but whatever the problem is runservice is at the heart of it.
Thanks for your reply nonetheless

OK from a cursory and limited read to the contents of the runservice.exe does not appear to be doing that much, but the devil is in the details:

It loads a library (dll) called mmfs.dll and perhaps a service mmfs.sys, then it uses the function ADVAPI32.RegisterEventSourceA to publish some event to the system perhaps that the mmfs are up and runing I don't know.
Some thing tells me that the brunt of the protection is carried by those mmfs files.
Check if they get created in memory. perhaps they are the ones that check so that runservice is continuously loaded all the time and sabotage the application if you unload it.

There are other more convoluted strategies to get into a module's code, break in and trace it. Look at this post, http://www.woodmann.com/forum/showthread.php?t=5853.

It works for me.

Good luck

Good thinking naides. The runservice exe does in fact load mmfs.dll and a file called mmf.sys I found something else out: the program checks for mmf.sys once about 10-15 seconds after the program is started. It will then check again at a certain intervals to see that mmf.sys is ok. If I close runservice it modifies mmf.sys so that the checks will fail. mmf.sys and runservice are part of the elicense protection software. All I have to do is eliminate the check (probably the best idea) or pass it good information (less desirable). I'll attach a little snippet of the filemon log when runservice is running for the dumped prog. It looks like the zsapi.dll that the dump loads might have something to do with it. I think there might be a crc check on the dll though because if I edit it there is an access violation on loading the program. My question is: how do I find where the dump accesses zsapi.dll for the mmf.sys check? I am not really familiar with how programs access dll files... I also have a feeling that zsapi.dll checks for more than just mmf.sys. I think that zsapi is causing all the problems and if I could just eliminate it from the dump it would work.

Several ways. The most obvious, which I doubt a protectionist would use is loading the dll at start and calling its exported functions. Look into the prog import list and the dll export list and see if they communicate this way.

Libraries can also be loaded dynamically at run time using the API LoadLibrary to load the file in memory and the api GetProcAddress to get a hold of code address the Starting point of the functions the program wants to call.

Sure enough the dll and the prog. both have the function zsapi.GetLoc in the export/import lists. I'm assuming there is going to be a spot or two that I need to get rid of in the dump. The dump calls the certain part of the dll it wants to access and then returns to the dump after it's done right? So it looks like I can do this two ways: 1. Find the dll crc check which I think is in the dump and eliminate it so I can just edit the dll directly (can crc's be hidden in dll's too?) or 2. Find where the dump accesses the dll for the 2 or so checks and get rid of them. I'm not really familiar with all this dll stuff but I have reversed some other things. Don't want you to think I'm an idiot because I'm not Just inexperienced, thats all.

How do you think we, the Idiots become experienced?

Changing any irrelevant code in the dll causes an error. I think that maybe the crc check is in the dll itself. I have checked the prog. and the dll for the createfilea code you mentioned and didn't find anything worthwhile.

If the dll has the crc embedded in itself, I think the best way to get rid of my problem is to get rid of the code in the prog. that calls for the dll. Even if I did get rid of the crc check in the dll there are probably too many functions in it I would have to patch to make the program work. So the thing to do would be to get rid of the code that accesses the dll.

Hate to sound stupid but have any other tips?


Once again thanks for your time naides.

It is more than likely that the program will not run at all without the dll, but it is always possible that it doesn't do anything but protection functions. It is rather a simply test if it is unnecessary. If you do remove the code from the program which calls the dll and re-run the program, you will quickly determine whether the program runs or not. My guess is that it will not run, but it could happen.

Regards,

Yes it looks like to me all the dll does is go through protection functions. It is filled with a bunch of stuff for elicense protection so I think that it is really not necessary... then again I could be wrong

Sort of a bump I still don't know how to get rid of this protection. There is a crc check on the dll that I need to remove. I think I can edit the dll protection functions so the program will run if I get rid of the crc check. My problem is I don't know what to look for. I have read some tutorials on crc stuff but still am having no luck. Any tips?

Ive narrowed the problem down but just don't know how to solve it. Any help is of course greatly appreciated

Innocent:

Using the main search function at the top of the Forums enter "CRC check" (without the quotes) and you will find several threads which might help you understand how CRC checks might work in your dll. You should also search on the net using phrases, such as "CRC Check" and "CRC + reversing." You will find, among others, an article titled "CRC and how to Reverse it - by Anarchriz" which is in one of the archives on our server. You will find it at :

http://www.woodmann.com/fravia/crctut1.htm

One of the Threads has a discussion by Kayaker about the APIs that might be called in CRC checking. Remember that it is going to process the file, dll or whatever in some and, generally, check it against some fixed value. Part of what you generally will be doing is trying to find the end of this process, where the result of the check is "tested" and determine what the result of that test should be if the code had NOT been changed and force it to return that correct result. This can get pretty complicated, but this is a good conceptualization of the problem.

Regards,

Heh always plugging the search function JMI I had already looked at the tutorial by Anarchriz before but it didn't help much. All the info about crc in the world doesn't help if you can't find where it is in the program. I did finally get rid of the crc check in the program so I could edit zsapi.dll. After a little softice tracing (Thank God for it!) I found what I needed to edit. It works perfectly now. Thanks to everyone who posted. I'm on to other projects now.

Congrats.
Now comes the pay-back. . .
Why don't you write a tutorial, explaining your thought process and the key points of the protection, and publish it in one of the available Tut collections,
so all of us can benefit from your findings.