search

icedland / iced

Blazing fast and correct x86/x64 disassembler, assembler, decoder, encoder for Rust, .NET, Java, Python, Lua
MIT License
2.91k stars 232 forks source link

`call qword ptr [2234h]` should probably be written as `call qword ptr [<something>+2234h]` #540

Closed JohnScience closed 6 months ago

JohnScience commented 6 months ago

I have little knowledge of assembly but I got confused when I saw a small hardcoded value in brackets, which is meant to be an address in 0x1800.... for x86_64 DLl.

The address seems to be RIP-relative.

JohnScience commented 6 months ago

Doing this:

if instr.code() == iced_x86::Code::Call_rm64 {
            let target = (fn_ptr as u64).wrapping_add(instr.memory_displacement64());
            println!("\t; Target: {:#x}", target);
        }

Seems to work properly at least for one case.

wtfsck commented 6 months ago

It shows the absolute address by default. If you wnat to see rip+xxx, there's a formatter option you can enable/disable.

JohnScience commented 6 months ago

It shows the absolute address by default. If you wnat to see rip+xxx, there's a formatter option you can enable/disable.

It's probably a poor default because if we don't specify the instruction pointer, it displays the incorrect value.

P.S.

Thank you for mentioning the option!

wtfsck commented 6 months ago

It's an offset relative to the current IP so make sure you set the correct IP when decoding and it should decode and format correctly.