Maybe replace 0xfffff with -1 ? about r2dec-js HOT 9 CLOSED

+1

from r2dec-js.

why closed? It's not fixed

from r2dec-js.

it is on x86

from r2dec-js.

https://github.com/wargio/r2dec-js/blob/master/libdec/arch/x86.js#L441

from r2dec-js.

I tried on master:

aaa ; pdd @ sub.SADFHUHF_10

Lab01-01.zip
(password is "infected")

label_0:
        edi = "hello";
        ecx |= 0xffffffff;
        eax = 0;
        __asm ("repne scasb al, byte es:[edi]");
        ecx = ~ecx;
        ecx--;
        eax = WS2_32_dll_send ();
        if (eax != 0xffffffffffffffff) {
            goto label_3;
        }
        eax = WS2_32_dll_shutdown ();
        if (eax != 0xffffffffffffffff) {
            goto label_3;
        }
...

from r2dec-js.

TL;DR: this is an r2 bug, rather than r2dec's

For the first occurrence, a bit-wise operation, I would like to see the actual bit-mask rather than a magic value. As for the two comparisons, r2dec recognizes the magical -1 value according to the underlying architecture, so I looked in the attached binary and noticed that the whole binary is in fact in 32 bits. That made me think -- what an immediate value of 0xffffffffffffffff is doing there in the first place ?

r2 interprets 83 78 ff as cmp eax, 0xffffffffffffffff although the 83 opcode is there to compare registers with an 8-bit immediate value. It is easy to see that this bug came out as a result of sign extension: try to replace the last byte of this sequence with 70h (MSB is clear), and then back to 80h to see the problem.

from r2dec-js.

The bottom line is, that r2 should have generated cmp eax, 0xffffffff. In that case, the disassembled output would show -1.

from r2dec-js.

I'll open a ticket for r2

from r2dec-js.

from r2dec-js.