PROG: Personal Password Vault v 1.0.1 URL: members.aol.com/princesoft BY: drlan [Me'97/C4N] ! TYPE: 32-bit PROT: Nag screen with time delay CHANGES: Output from FC ppv.exe ppb.bak /b Comparing files ppv.exe and ppv.bak 000271B2: 66 E8 000271B3: 40 9D 000271B4: 90 DB 000271B5: 66 FD 000271B6: 48 FF 0003FAD6: 4F 61 0003FAD7: 54 67 This tutorial is more of a request for someone to teach me how to crack this program's nag screen more elegantly. I ended up using what I'd consider a very "dirty" crack. I'd love for someone to show me a "cleaner" approach to cracking this nag screen. Anyway, with a little brute force, here's what I ended up with... The protection on this program is a nag screen with a timer, very annoying. So, let's crack this babe! First I loaded up PPV.EXE in QVPlus to look for the program's type (32-bit) and to see if there were any interesting imports. Actually the imports looked garbled and I didn't see anything interesting. I've read elsewhere that nag screens often use the following functions to do their nasty work: 16-bit 32-bit MessageBox MessageBoxA DialogBox DialogBoxA This is a 32-bit app, so I tried setting BPX MessageBoxA and BPX DialogBoxA in SoftICE. I loaded the program up. It asked for my password, prior to the nag. Then the nag screen loaded up. Bummer, sICE didn't pop. So our babe doesn't use the standard functions to display the box. Damn. Now, I'm stuck because I don't really know how to break on the custom code. I tried finding the Window handle and setting a breakpoint on the mouse click once the button became visible. To find the right window handle to break on, simply type HWND in the sICE command window. It will show you a list of all the windows. The table is dynamic and takes on a parent/child form. Look for the one with PPV (our babe). Then look for child windows a class name of "Button." I did this and set a breakpoint to pop when I clicked the button. This was done via BMSG 0378 wm_lbuttondown. Your window handle number will differ... My hope here was to look at the stack to see if I could find the call that brought me here. I couldn't... So, I disassembled PPV.EXE with W32Dasm 8.5. A very nice tool for just such a job. Then I clicked on the String Reference button to see if I could find anything interesting, like perhaps text from the nag screen. Nope! In fact, there really wasn't any interesting text. Man, there must be an easier way. I guess the strings aren't there because our babe is compiled with a Borland product, perhaps C++ or Delphi. These store strings differently to where they can't be seen when disassembled. Ok, so it's a Borland product... Let's use a Borland product to continue the cracking efforts. Next I load it up in Borland Resource Workshop 4.5 and have a look around. Hmmm, here's something called TFormNag. One of Fravia's tutes said I could simply delete the resource and BRW would re-compile for me. So, that's what I did. I deleted the function, exited BRW, saved our babe, and ran it. I got a messagebox complaining about "resource TFormNag could not be found," or something to that effect. When I clicked ok on the messagebox, the program popped right up and ran fine. This looks a little better. Now I set a breakpoint on on MessageBoxA to pop at the error message. After dicking around in sICE a little using STACK to see my last few instructions, I finally found the instruction that called the MessageBoxA function. The code (taken from W32Dasm) looks something like this. If you want to avoid trying to find this junk yourself, just disable the existing breakpoint. Then set a new breakpoint at 0137:00427DB2. Then run the program. If sICE doesn't pop, then you'll need to translate the segment:offset address to a "real" one. Some of the tutes explain how to do this. Then you'll have to find the right segment:offset for your machine. Again, this is explained in other tutes. * Reference To: user32.MessageBoxA, Ord:0000h | :00427DB2 E89DDBFDFF Call 00405954 :00427DB7 8945FC mov dword ptr [ebp-04], eax :00427DBA 33C0 xor eax, eax :00427DBC 5A pop edx :00427DBD 59 pop ecx :00427DBE 59 pop ecx :00427DBF 648910 mov dword ptr fs:[eax], edx :00427DC2 68E07D4200 push 00427DE0 I want to skip this call because I know that once the call is done (e.g., I click on ok), I am taken right into the program. I know, I know... I am cracking the symptom (an error message), not the problem (the actual nag). Seeing that the call to MessageBoxA is 10 bytes, I don't really want to stick in 10 NOPs, so I do the +ORC trick: (Type A in the sICE command window to ASM in the following instructions. Type ESC when finished. Then press F5 to run the program.) A :00427DB2 6640 inc ax :00427DB4 90 nop :00427DB5 6648 dec ax ESC F5 which leaves :00427DB7 in tact and doesn't introduce too many NOPs (just in case our babe sniffs them out). I press F5 to continue running and viola, it works fine. Boy I hope this call doesn't really do anything else, or I could have just made a big mess. I did test out most functions and everything looked ok. Alright now to make a patch. I start comparing the original file with my now cracked version and find they are way the hell out of whack. Remember when I removed that whole function using BRW, well that took a big bite out of the code. So, now there's now way to make a patch. Damn. So, I return to the original (uncracked) program. Load it up in a hex editor and look for TFormNag. Sure enough, there it is. I wonder what will happen if I change the name. Perhaps it will call our error routine to tell us that "resource blahblahblah can not be found." So I change the first occurance of it to TFormNOT. Run it. Yep, there's our error "resource TFormNOT could..." So now, just patch back in our inc ax, nop, dec ax at the appropriate place. This can also be done in the hex editor. Search for the following hex bytes: 50 E8 9D DB FD FF 89 45 and change the following: ^^ ^^ ^^ ^^ ^^ 66 40 90 66 48 Now our babe runs much better, without the nag. But, this is definately not a "clean" crack. Would someone please teach me how to crack this thing the right way? Thanks, drlan [Me'97/C4N] !