#1
|
||||
|
||||
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 Last edited by squareD; 02-15-2006 at 01:53. |
#2
|
|||
|
|||
Quote:
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 |
#3
|
|||
|
|||
i dont know but you may have wrong code here, because when we operate on byte ror 8 will give exactly same value
|
#4
|
|||
|
|||
Maybe I'm wrong or don't understand but..:
AF -> NEG -> ROR 6 = 45 65 -> NEG -> ROR 7 = 37 7F -> NEG -> ROR 3 = 30 |
#5
|
||||
|
||||
@Human
No, the code is correct and still all found bytes are accepted by program. @adaptor You did understand very well. 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... 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 Last edited by squareD; 02-15-2006 at 17:30. |
#6
|
|||
|
|||
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 |
#7
|
||||
|
||||
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 |
#8
|
|||
|
|||
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). |
Thread Tools | |
Display Modes | |
|
|