[spam][crazy] bomb malware
Karl
gmkarl at gmail.com
Tue Dec 14 04:00:37 PST 2021
// 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
More information about the cypherpunks
mailing list