Mathematical impossibility?
 

There is a given IdentCode calculated by ProductId of system.

Author of program compares HexCodes of IdentCode with RegistrationCode by doing this:

1st byte of RegCode -> NEG -> ROR 1 = value
...
8th byte of RegCode -> NEG -> ROR 8 = value
9th byte of RegCode -> NEG -> ROR 1 = value
...
16th byte of RegCode -> NEG -> ROR 8 = value

This means:

IdentCode................ = C5CA0E7A3B0433BD
HexCode of IdentCode = 43 35 43 41 30 45 37 41 33 42 30 34 33 33 42 44
Found RegCode......... = 7A 2C E6 EC FA ?? ?? BF 9A F7 7F BD 9A 34 DF BC

Not found:

?? -> NEG -> ROR 6 = 45
?? -> NEG -> ROR 7 = 37
?? -> NEG -> ROR 3 = 30 FOUND!!

In my opinion it's impossible to get out these values by using only one byte.
But may be that I'm wrong.

Program is cracked in meanwhile, but anyway I'm interested in figure out, how this guy would register this program, if I had bought it.

Thus I present here for discussion.

EDIT: Just found corresponding byte for 30...

Regards,
squareD

Why do you think it's impossible? You are probably mixing up bit shifting and bit rolling. ROL/ROR move the bit that drops out of the byte into the other end of the byte. Maybe an example helps:

0x30 -> b00110000, ROL (inversion of ROR) that three times, you get:
0x60 -> b01100000
0xC0 -> b11000000
0x81 -> b10000001

You must not try to just multiply by 2 here :) This is the essential difference between ROR/ROL and SHR/SHL :)

i dont know but you may have wrong code here, because when we operate on byte ror 8 will give exactly same value

Maybe I'm wrong or don't understand but..:
AF -> NEG -> ROR 6 = 45
65 -> NEG -> ROR 7 = 37
7F -> NEG -> ROR 3 = 30
:D

@Human

No, the code is correct and still all found bytes are accepted by program.

@adaptor

You did understand very well. :D

I worked with 32bit calculator by cybult.

45 -> ROL 6 -> NEG = EECO
and your example
AF -> NEG -> ROR 6 = 44000001

Seems like there are bugs in this calculator... :mad:
Think I have to search another one.

Thanks a lot to you and a new member nicknamed laola, who wrote me a private message.

Regards,
squareD

SquareD: you should practice doing such basic math in your head ;) As you described the algorithm in your first post, all bytes are handled individually. My advice would be putting the calculator aside and doing the math on a piece of paper. Single bytes are easy to convert to binary notation, just write them down, then manipulate the bits according to the steps the algorithm takes, and see how it turns out. Calculator apps frequently run into overflow/underflow issues, it's just a natural side effect of how they work.
It's just like with every tool - you have to know how to handle it properly to make full use of them.
And by the way, it's very convenient if you are trained enough to read hex and binary just or almost like decimal values :)

Absolutely right...

Shame over me, but I'm out of training since years. :(

Unfortunately I familiarized myself to use tools, to spend not too much time for cracking and something like that.
But this experience taught me, which it was an mistake.

Next time I will take a piece of paper and my pencil to do RORing and ROLing with ones and zeros by myself. :)

Regards,
squareD

The cybult's calculator work ok,at least i do not found any bug since use them.
But that is 32bit calculator - data entered as ROL/ROR operand is treated as 32bit (DWORD) value, not as 8bit (BYTE).