Quick IFSF challenge 10 writeup We are given a 16bit DOS executable. We're gonna solve this with IDA and debug.exe :) Should be fun. When run, programs changes the colours and displays "Authorization code:" string. Than it waits for input. It expects 9 characters. If you enter the wrong ones the program exits. Running strings on this binary reveals nothing. But, upon closer inspection in IDA, we can spot a simple decrypt loop. seg000:02D0 decrypt proc near seg000:02D0 seg000:02D0 mov bx, word_1011A seg000:02D4 xlat seg000:02D5 xor cx, cx seg000:02D7 mov cl, al seg000:02D9 push es seg000:02DA push cs seg000:02DB pop es seg000:02DC mov di, si seg000:02DE seg000:02DE loc_102DE: seg000:02DE lodsb seg000:02DF xor al, dl seg000:02E1 stosb seg000:02E2 dec cx seg000:02E3 jnz short loc_102DE seg000:02E5 pop es seg000:02E6 assume es:nothing seg000:02E6 retn seg000:02E6 decrypt If we use debug.exe and set the breakpoing at 2d0 (-g 2d0), we can inspect what is actually decrypted. Turns out that first call of this function actually decripts "Authorization code:" using 0x99 as a key. Second call decrypts the string "Yep!" using 0xAA as a key. Well, that's all nice and pretty, but doesn't help us to get the flag. Now, lets check what happens when we enter nine chars. After some transformation, it gets compared to following bytes: A08B987B6390989063 If it's the same , we win. Lets find out what the actual transformation is. We find this piece of code: seg000:0277 rol al, 3 seg000:027A xor al, 19h seg000:027C mov [si], al seg000:027E inc si So, our initial input is ROLed 3 times , than XORed with 0x19. It is obvious that this can be reversed. So if we apply XOR by 0x19 and ROR 3 times to that hardcoded hex string we should get the key. Do the transformation and you get: 7R0LO101O Check that in the prog, and it's correct. So that is our flag. Nice little challenge without to much trouble, altho the colour change in debug.exe was somewhat painfull :) Cheers, ea