// dereference the pointer and move the discovered value into EDX. // ghidra here is reminding us that PTR_DAT_0804e024 in EAX points to DAT_0804e00c // and if one of those values is renamed in the interface, it will update the name everywhere 080480e0 8b 10 MOV EDX,dword ptr [EAX]=>DAT_0804e00c // comparing a value with itself tests whether it is zero or not 080480e2 85 d2 TEST EDX,EDX // if the pointed to value is nonzero, goto 080480d1 080480e4 75 eb JNZ LAB_080480d1 // reset the active pointer (eax) to zero 080480e6 b8 00 00 MOV EAX,0x0 00 00 // this looks like a compilation quirk, and i'll include the two lines together // since eax is always zero, this is always a jump to 080480ff, right? // it's the cryptic termination of the while loop, right? 080480eb 85 c0 TEST EAX,EAX 080480ed 74 10 JZ LAB_080480ff // i'm not experienced with disassembling malware. it's possible some code jumps to 080480eb that ghidra hasn't detected, or maybe this is some compilation norm. // this code looks like the end of a function, but presently it would never be executed, due to the jump above 080480ef 83 ec 0c SUB ESP,0xc 080480f2 68 08 df PUSH 0x804df08 04 08 // this instruction makes no sense to me: calling 0x00000000 as a function. this would immediately segfault an application. maybe it is there for that purpose? maybe it is there to be replaced later? 080480f7 e8 04 7f CALL SUB_00000000 fb f7 080480fc 83 c4 10 ADD ESP,0x10 // here's where normal execution would resume, the end of the while loop. it sets the flag to 1 (true). LAB_080480ff XREF[1]: 080480ed(j) 080480ff c6 05 80 MOV byte ptr [BOOL_0804e080],0x1 = ?? e0 04 08 01 // and returns. LAB_08048106 XREF[1]: 080480cf(j) 08048106 c9 LEAVE 08048107 c3 RET