How do I interpret this disassembled code in IDA?
It looks like you're looking at the decompiled output. Since there is no type information in assembly, the decompiler seems to think the memory addresses were just plain integers.
char *s; // [rsp+18h] [rbp-18h]
shows that s
is an address to where the string is stored. if ( strlen(s) != 8 ) exit(3);
means the length of the string in s
should be 8
, or otherwise the program will exit with an error code 3
.
if ( checkpw((__int64)s, 0LL, v3, (__int64)s) )
here the address of s
is passed to checkpw
, not the value, and I don't know why it is passed twice.
Looking at the body of checkpw
,
_BOOL8 __fastcall checkpw(__int64 a1, __int64 a2, __int64 a3, __int64 a4)
{
unsigned __int8 v5; // cl
char v6; // cl
_BOOL8 result; // rax
result = 1;
if ( (*(_BYTE *)a4 ^ 0x52) == 17 && *(_BYTE *)(a4 + 7) == 35 )
{
v5 = *(_BYTE *)(a4 + 1);
if ( (v5 ^ *(_BYTE *)(a4 + 2)) == 64 && v5 == 115 )
{
v6 = *(_BYTE *)(a4 + 3);
if ( v6 > 35 && !__OFADD__(91, v6) && (*(_BYTE *)(a4 + 4) ^ 0xF3) == 0xC7 && (*(_WORD *)(a4 + 5) ^ 0x4C47) == 4660 )
return 0;
}
}
return result;
}
the first argument a1
isn't even used, so you can just ignore the first s
passed to a1
.
I cannot do all of the decompiled bitwise logic for you in the body of checkpw
, but if you grab a programmer's calculator and test with some possible inputs while looking at the hex and binary dump, you may find a hint.
Also, have a look at the ASCII table, it will help you a lot understanding what checkpw
is doing. It seems it is doing a series of direct comparison with each character in the string to a certain ASCII value to check if the password is correct.