Log in

View Full Version : Cracking Protected App, with routines in dll


sccs
May 2nd, 2007, 23:46
What is the problem....
Problem im having is, the program im trying to crack is both protected and as far as i can tell has its registration routines contained within seperate .dll files.

What is the protection.....
the protection is armadillo 3.xx-4.xx i have managed to unpack the main exe,

What tools are you using....
ollydbg, ultraedit,

What tutorials have you read....
several on armadillo and many on basic serial hacking.

NOW ask your question....

basically i can get my head around unprotected software with ease. armadillo had me stumped for a short while but i found tutorials on that.

the problem im havein is i cannot seem to find a real key, i have tried bp on string references and back tracking through the code, even tried the hmemcpy breakpoints. all work and jmp to the correct place within the program usually a few lines for the "invalid serial" code.

i beleive the routine may be contained either in a dll or mixxed between the dll and the main exe, if someone could point me in the direction of a tut that shows cracking with dlls involved i would be very greatful. or am i barking up the wrong tree.

the key is a username and serial.
no online check that im aware of.

thanks in advance.

squidge
May 3rd, 2007, 01:58
Well, if it asks for the serial via a message dlg, you may want to investigate calls to GetDlgItemText and go from there? If the routines are not near that, as least you can set a BP on the result and catch it whenever it does check it.

fr33ke
May 3rd, 2007, 04:18
If it's using Armadillo's key system (and usually protected programs do), it can be very very hard or even impossible to get a key. Fishing surely won't help.

You're better off just unpacking everything and setting a breakpoint on GetEnvironmentVariableA.

sccs
May 3rd, 2007, 04:42
Quote:
[Originally Posted by squidge;65358]Well, if it asks for the serial via a message dlg, you may want to investigate calls to GetDlgItemText and go from there? If the routines are not near that, as least you can set a BP on the result and catch it whenever it does check it.


thanks for the reply. this is what i have been doing. the bp i been using breaks at the getdlg i can find the capture of the input no problem, just having problems tracing the serial/activation..

Quote:
[Originally Posted by fr33ke;65362]If it's using Armadillo's key system (and usually protected programs do), it can be very very hard or even impossible to get a key. Fishing surely won't help.

You're better off just unpacking everything and setting a breakpoint on GetEnvironmentVariableA.


thanks for the info m8.. looking at an old key i got *********-4MMA-150E-SFKW-3SP3-0188 im guessing your prob correct.

looks like best way may be to just bypass the check all together then?

i have a found old version that has already been cracked. im guessing that if i compare the old cracked and uncraked files it may help?


thanks.

naides
May 3rd, 2007, 05:43
Quote:
[Originally Posted by sccs]
i have a found old version that has already been cracked. im guessing that if i compare the old cracked and uncraked files it may help?

thanks.


Certainly it is an avenue to explore, assuming that the old version has a similar protection than the new/current. I placed a link to Andre Protas diffing suite in a previous post, which I have found useful.

Other relevant questions:

Did you unpack the main exe AND all the packed dll?

Are you aware of decoy/false leads in the code, or that sometimes coders leave in the code some objects/functions remnant from previous protections but not relevant to the current protection?

squidge
May 3rd, 2007, 07:13
Does the program immediately ask for the serial on startup, or after it has already run and shown the splash/etc ?

sccs
May 3rd, 2007, 07:24
it shows a small splash screen, says how many days left, and gives 3 options try, buy, enter serial...

once unpacked there is no splash screen and the days left jumps from 6 to 20,

i have tried to unpack the dll but it seems its not packed, peid reports it as Microsoft Visual C++ 6.0 DLL


ok... some success.. i compared the old original .dll and the patched one and found only 3 differences, one is to noop a jnz , and 2 to change xor's to mov's. searched through the new .dll and found the correct locations to patch. i applied the same principle as the other patch, i nop'ed the jnz and changed xor's to mov's... am i missing something with altering the .dll i applied the patch through olly and applied the changes to executable. or was that wrong,. never dealt with dll modification before. any tuts knocking around.

ok i modified the old dlls my self and all went well so i must be missing something in the new dll.
when i modify the new dll in the same way as the old ones i get a error message telling me that the dll is corrupt. even tho this happens, it has bypassed the splash/nag screen. as there is a sound that is played when the program starts. this plays then i get the error message above. is it possible that they have implemented a crc/md5 check into the programs? if so is there any point in continuing?

any help most appreciated.

squidge
May 4th, 2007, 02:02
I've never heard of a "DLL is corrupt" type message, so I can only assume it's either checking itself, or something else is checking the DLL for modification.

naides
May 4th, 2007, 18:57
Quote:
[Originally Posted by sccs;65374]
ok... some success.. i compared the old original .dll and the patched one and found only 3 differences, one is to noop a jnz , and 2 to change xor's to mov's. searched through the new .dll and found the correct locations to patch. i applied the same principle as the other patch, i nop'ed the jnz and changed xor's to mov's... am i missing something with altering the .dll i applied the patch through olly and applied the changes to executable. or was that wrong,. never dealt with dll modification before. any tuts knocking around.

Modifying .dll code or modifying the main exe code amount to the same, and are the bread and butter of cracking . There is nothing mysterious about dlls. Think of it as if the code has been split into several files that call each other when needed. (Not a completely accurate statement, but close enough).

ok i modified the old dlls my self and all went well so i must be missing something in the new dll.
when i modify the new dll in the same way as the old ones i get a error message telling me that the dll is corrupt. even tho this happens, it has bypassed the splash/nag screen. as there is a sound that is played when the program starts. this plays then i get the error message above. is it possible that they have implemented a crc/md5 check into the programs? if so is there any point in continuing?


There is plenty of point in continuing, integrity checks happen often in protections, but can be bypassed.
For starters find out which file/process displays the error message "corrupt .dll" by placing bp in APIs that show that window, or by searching for the text of the error message in memory or disk, or by monitoring who reads the .dll file .

The decision to display the error message should be near by. . .

Then neutralize the integrity check



any help most appreciated.



In Royal Blue


FrankRizzo
May 4th, 2007, 20:05
Quote:
[Originally Posted by sccs;65374]is it possible that they have implemented a crc/md5 check into the programs?


Definitely! I worked on an app that used Microsoft's stock MD5 routine to hash the .dll, and verify that it hadn't been monkeyed with. (Since I'm telling you this, I obviously found that section in the code, and could monkey to my heart's desire

Quote:
[Originally Posted by sccs;65374]
if so is there any point in continuing?


ABSOLUTELY! It sounds like you are almost there! Probably patch up that check, (and maybe a later check of the main program), and you're done!

Once you get it going, I'd recommend pulling apart that .dll, and having a look at how the crack actually works. Otherwise, you'll have learned nothing useful about this particular app. (Well, other than it's packed with Armadillo, and checks it's .dll).

sccs
May 4th, 2007, 20:17
hi guys...

@naides
thanks for the info.
it didnt cross my mind to breakpoint the dll error gonna give it a go now.

@FrankRizzo
this for the info also..
i understand why and what 2 of the modifications are doing, as for the third still working on it. as there is no code arround that stands out so needs a good look to figure its function.

another update.....

had a go at bypassing the check and i got it..... great i thought... but by bypassing the check i seem to have disabled the function of the program.. program loads fine and runs ok. but it doesnt show what its ment to. cant go into detail as it will give away the name software. guess ill have another go...

another update......

checked the original and same problem. then i noticed an update was available so i downloaded the update and started again...

and sucess.... just got to wait and see if the i have killed the trial and not just bypassed it displaying...

i thank you all for the help... and keeping me workign at it. trial ends sunday so i will let ya know if it worked then..

thanks again..

squidge
May 5th, 2007, 11:02
I find virtual machines invaluable for testing time trialled software. You can patch, change the date, run, and if it didn't work, you can simply roll back all the changes and try again

Of course, some software can now detect virtual machines and refuse to run, but those are few and far between.