# Disassembly - Why the CMP instruction is multiplying by 2 the value being compared

I'll get right to the point, I have a crack me program, that is a program with a password inside that needs to be found so that you can complete the challenge.

I easily found the cmp instruction with the password, but the numeric password was multiplied by 2.

in the program does not have anything to multiply or divide the password, then this must be caused by something else

so I had to get the hexadecimal value of the password convert to decimal and divide by 2 to have the real password.

here is the cmp instruction:

CMP DWORD PTR SS:[EBP-C],961DB0

0x961DB0 / 2 is the password.

I would like to know why the password has been multiplied by 2 in this cmp instruction.

A photo of the Source Code, I do not have it without being in the photo.

Thank you very much in advance.

• Can you replace those photos with the real code? It will make question better and reproducible for others. – Biswapriyo Sep 23 '18 at 12:23

The cmp instruction does not multiply anything by two. Instead, the piece of code seen in your ollydbg screen shot is the implementation of the following line from the poor quality source code image you attached:

if ((!key) || (key > (0x1337 * 2000)))

First, in address 0x01051C09, key is compared to 0. If key equals 0 a jump to 0x01051C18 is taken. Otherwise, key is compared to 0x0961DB0. If key is below or equal to 0x0961DB0 another jump is taken. If key is greater than 0x0961DB0 execution continues to 0x01051C18.

As you should've guessed by now, 0x0961DB0 is simply 0x1337 times 2000.

Instructions 0x01051C18 to 0x01051C22 are the implementation of calling wrong, setting eax to the correct return value (1) and then jumping to where (I assume) the function prolog and ret are executed.

• Thanks, but suppose we did not have the source code, how could we identify that 0x0961DB0 is 0x1337 * 2000? – AqueleCaraComNome Sep 23 '18 at 1:25
• We would not necessarily recognise that. Instead, we may write condition as key > 0x0961DB0. It's essentially the same. – NirIzr Sep 23 '18 at 1:27
• Now I understand, thank you for clarifying the problem. – AqueleCaraComNome Sep 23 '18 at 1:32