# Easy KeyGen

We will be solving the Easy\_CrackMe challenge.

Download Location : [Reversing.kr](http://reversing.kr/download.php?n=2)

## Static Analysis

Opening the binary in IDA shows the graph view of the entry function `main`. The entry function is fairly simple.

![Disassembled view of main function](https://1804885456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIo3S6x9y21ea77Yw303B%2Fuploads%2FIDpXzI8VsrUPV8vbbwKG%2FCapture.PNG?alt=media\&token=fd6be2af-6b39-4992-9ade-d62a35877e98)

As per static analysis of the binary by IDA, we notice that there are computations being done on the `InputName` which is then later checked against `InputSerial` via `strcmp` function call. 

As mentioned in the challenge, we need to find the input for Serial Key : `5B134977135E7D13`

#### Incorrect Detection by IDA

Noticing the for loop presents us with a problem where `i` is made `0` by the `if` condition inside the `for` loop and later element in array of `v7` is accessed at `i-1` i.e `-1` index which is not correct. 

We now dive into the corresponding assembly code to understand if this was Decompiler issue.

![Assembly code](https://1804885456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIo3S6x9y21ea77Yw303B%2Fuploads%2FBvu0WSWRpMcgNKYedR7v%2FCapture1.PNG?alt=media\&token=4465c0ca-c544-4726-9ac3-a77c64e27abb)

The first thing to notice is in one of initialisations `mov ecx,31h` instruction has been executed setting ecx to 0x31. 

```nasm
or ecx,0xFFFFFFFFh
not ecx
dec ecx
test ecx,ecx
jle <address>
```

The above are the instructions that directly affect ecx and controls the jump to another address. The instruction `or ecx,0xFFFFFFFFh` returns back `0xFFFFFFFFh` . Next instruction `not ecx` performs bitwise NOT operation and sets ecx to `0`. Next instruction `dec ecx` decrements ecx further and sets it to `-1`.  When `test ecx,ecx` is executed, it is found that ecx is is signed int with ZF not set . Since ZF flag is not set, jle is not taken up and the next instructions gets executed.

```nasm
cmp esi,3
jl <address>
xor esi,esi
```

The above instructions can be translated into

```c
if(esi < 3){
    <jump to another address and execute instructions>
}
else {
    esi=0;
    <execute instructions below this>
}
```

Also, as evident from movsx instructions, the decremented esi is directly used to reference variable and there is no external decrement of esi by 1. Hence `v7[i-1]` shown by IDA should be `v7[i]`.

```nasm
movsx ecx,[esp+esi+13Ch+var_130]
movsc edx,[esp+ebp+13Ch+var_12C]
```

This clearly means that the disassembled code by IDA was incorrect. The for loop could be therefore re-written as :-

```c
for(i=0;v3<strlen(v8;i++){
    if(i >= 3)
        i=0;
    sprintf(Buffer,"%s%02X",v8[v3++] ^ v7[i]);
```

#### Finding v7 Variable

IDA has been referencing `v7` in the code for XOR operation with the supplied input implying there must be some hardcoded value to v7.  As evident, v7 is an array of size 3. So we are looking for 3, 1 byte memory (`movsx` instruction takes a BYTE) blocks with some initialised value.

Looking in the assembly code, we find that this array consists of `0x10`,`0x20` and `0x30`.&#x20;

![array present var\_130](https://1804885456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIo3S6x9y21ea77Yw303B%2Fuploads%2FabJIiERjhdFMn3jMcIZq%2FCapture2.PNG?alt=media\&token=a03a438a-5067-4131-aed9-dbb566799ed7)

#### Solution

```python
serial = "5B134977135E7D13"
print(f"[!] Input Serial: {serial}")

l_serial = len(serial)
print(f"[!] Length of serial: {l_serial}")

counter=0
input = ""
for i in range(0,l_serial,2):
	ch = serial[i:i+2]

	int_ch = int(ch,16)
	if counter == 3:
		counter=0
	if counter == 0:
		op = chr(int_ch ^ 0x10)
	elif counter == 1:
		op = chr(int_ch ^ 0x20)
	elif counter == 2:
		op = chr(int_ch ^ 0x30)
	counter=counter+1

	input = input + op

print(f"Input: {input}")
```

The above script will fetch the input as `K3yg3nm3` which is the correct input for passed serial number.