I've been playing around with this target off and on for months and I think the registration option in this target is bogus and it can't possibly be registered. If you buy the program they send you the "real deal" along with a key - here is part of the password checking code -

:0050C0FC A1D0F45100 mov eax, dword ptr [0051F4D0]
:0050C101 8B00 mov eax, dword ptr [eax]
:0050C103 8B9020080000 mov edx, dword ptr [eax+00000820]
:0050C109 8BC3 mov eax, ebx
:0050C10B E8A0D9EFFF call 00409AB0
:0050C110 56 push esi
:0050C111 8D45F0 lea eax, dword ptr [ebp-10]
:0050C114 50 push eax
:0050C115 8D45F8 lea eax, dword ptr [ebp-08]
:0050C118 50 push eax
:0050C119 53 push ebx
:0050C11A A1E0F15100 mov eax, dword ptr [0051F1E0]
:0050C11F 8B00 mov eax, dword ptr [eax]
:0050C121 FFD0 call eax -> Call to system dll
:0050C123 8B4508 mov eax, dword ptr [ebp+08] -> Moves entered password into EAX
:0050C126 8B550C mov edx, dword ptr [ebp+0C]
:0050C129 81F0533E5D8D xor eax, 8D5D3E53 -> XOR password with this value
:0050C12F 81F201000000 xor edx, 00000001
:0050C135 3B55F4 cmp edx, dword ptr [ebp-0C]
:0050C138 7509 jne 0050C143
:0050C13A 3B45F0 cmp eax, dword ptr [ebp-10] -> compares XORed password with 43150000
:0050C13D 7504 jne 0050C143
:0050C13F B001 mov al, 01
:0050C141 EB02 jmp 0050C145


Well the problem is that the password should be 43150000h XOR 8D5D3E53h,
However any number XORed with the value above produces a 10 digit integer, the target will only accept a 9 digit integer password - my question is am I totally nuts or am I missing something?

SiGiNT

First of all, please tell me how many digits (8D5D3E53h XOR 8D5D3E53h) has? See what I mean?

And just in case that wouldn't be it, are you sure you're not missing anything related to decimal vs hexadecimal digits?

dELTA,

Point taken, but, and I'm no math whiz - always thought music would support my sorry ass LOL, CE483E53h XOR 8D5D3E53h = 43150000h.

CE483E53h = 3460841043 dec. 10 digits.

Like I said I'm no math whiz but thats the numbers I come up with.

SiGiNT

There is the possibility that the hex value is signed. That would make CE483E53 equal to -834126253. Which is nine digits

I think I've been mislead by the code, happens a lot, it could be a bogus routine to fool idiots like me - the target will accept 1111111111 but not 2222222222 - so it looks like I'm on the wrong track.

SiGiNT

Surely your first move (with any algorithm) should be to live-patch some jumps to see if the algorithm has a branch you can aim towards (i.e. put the horse before the cart - make sure this algorithm is indeed your hot spot, then get to reversing it). If it does have an exit with the desired results, and the algorithm is non-degenerate then it can't be bogus.

Admiral,

Patched it several different ways, all successfully got me to the <target> Registred (sic) message, yes it's actually spelled that way, the mov al, 1 sets the flag to pass the test for the jump to the message, it then calls a subroutine that contains a call to a system routine, if that routine returns it immediately calls another routine that disables the menu items. This lead me to the conclusion that patching would be more difficult than reversing the password, based on the assumption that the values contained in eax and edx are tested elsewhere, back tracing the code is not easy as this is a compiled Delphi app. One of the reasons this target piqued my interest is that a friend asked me to take a look at it, and it is used extensively in university courses in europe, that usually means that a fix should be easy to find - but I can't find one.

SiGiNT

I pretty much assumed that patching the code this way should work perfectly, when it didn't I came here looking for ideas -

:0050C123 8B45F0 mov eax, dword ptr [ebp-10]
:0050C126 8B55F4 mov edx, dword ptr [ebp-0C]
:0050C129 81F0533E5D8D xor eax, 8D5D3E53 -> nop this out
:0050C12F 81F201000000 xor edx, 00000001 -> nop this out
:0050C135 3B55F4 cmp edx, dword ptr [ebp-0C]
:0050C138 7509 jne 0050C143
:0050C13A 3B45F0 cmp eax, dword ptr [ebp-10]
:0050C13D 7504 jne 0050C143
:0050C13F B001 mov al, 01
:0050C141 EB02 jmp 0050C145

Added later.

SiGiNT

Okay, I see.
I wasn't suggesting that you should patch this app rather than keygen it, but now that I see why you are looking to reverse the serial, perhaps there is indeed an easier way.

Have you yet determined whether it is the same piece of code responsible for this secondary behaviour? If it is, perhaps you could try and apply a more permanent patch (patch over the instructions rather than changing flags on the fly) and setting hardware access breakpoints on the patches themselves to see if the app is detecting, or removing your patches (also if that code is executed again). If the breakpoints don't trigger, chances are that there is another area that will need addressing. If the crippling technique employed really is one-fold, then a well-tailored API breakpoint or two should bring you to this second anticrack routine with little hassle.

Good luck
Admiral

Admiral,

I believe that what you are suggesting it's absolutely the case - what I show here is the end of a very convoluted sequence of jumps and routines, I assumed that since it was still checking the original entered number I could still dig out the actual serial number, that 43150000h value could be already set-up as a trap many lines of code back - as my self-imposed title suggests, I'm a newbie to the world of modern reversing - actually the first RE that I did was to remove the copy protection from disks, or tapes created on TI99A computers in the 70's that's where I learned assembler, just reaquired the lust to do some reversing again recently. I may shelve this one untill I gain a little more experience, especially more knowledge of API's.

Thanx for the help.

SiGiNT

A word about the secondary behavior, the NAG - you can't do this with the demo version. It is not called from a central location - the nag is placed in many areas of the code - this is a small circuit simulation program, if you try to add a resistor it calls the nag from one address, a capacitor, the nag comes from another, about 8 - 10 different locations in the code - the dead listing always traces back to a Dword look-up table. Challenging to say the least, I suspect the author has a lot of RE experience.

Hi sigint33,



What is this system dll function?
Because the function will store the "true" serial at EBP-10, atleast I think (I can't know for sure because I don't know what the system call does but you can see that the system call has a parameter to EBP-10).



Do you know if EDX (ebp-0C) has anything to do with the (real) serial? (It probably has because if EDX is not equal to EBP-0C then the routine returns bad... but what indicates the value in EDX?)

Have you also tried to enter "CE483E53" as a serial?
Or are you absolutely sure that the serial can only be numbers and not hexadecimal?

You could also patch the 2 JNE's at 0050C138/0050C13D to NOP's to make it return 01 in AL (Or code a little "mov al, 01/ret" at the end of the routine )

Ok, I think I asked enough for now

Regards,

CoDe_InSiDe

Sounds like fun.

I'm sure this isn't the easiest was to deal with the situation, but I'd be tempted to give it a pin, if just for the entertainment:
Perhaps you could try to hook User32 or code inject to add some 'functionality' to EnableMenuItem's memory image. By testing the parameters as the function prepares, you could catch and bypass any efforts to set a menu item to MF_GRAYED.

Then again, maybe I should stop dreaming up contrived solutions and let you do it your way :P

@CoDe iNsiDe,

I've pretty much already done what you have suggested, the system call is to nt32.dll, (if my memory is accurate!), but then again that depends on EAX.
The MOV AL, 1 is kind of unusual, it makes it inequal when the routine returns and a TEST AL, AL > a fail proceeds to the reg. success message, but of course it doesn't work. I've pretty much determined that this section of code is the last test in a series of PWD tests, and if they all aren't satisfied it won't run.

@Admiral,

I'd be happier if the menu disable routine caused items to be greyed out, a couple of PUSH's in the right direction would fix that, if you read my earlier post what it does is issue a nag when certain operations are attempted. I will PM you the target's name, I think you'll find it entertaining for sure , there are all kinds of intriguing possibilities - there is a section that ref's "fungame" and another that ref's "for internal use only", I have to think this author is having a little fun.

SiGiNT

I predict that Admiral will say that even his kid brother who only plays with X-boxes figured it out in 5 minutes!