In fuzzing (with Pintool) to get examining execution traces of the program, here it is wget. I get some weird instructions, following is a piece extracted from a (very long) trace:

RIP register   instruction

0x7fff751fed17 mov rbx, 0xffffffffffdff000
0x7fff751fed1e lsl r11d, eax
0x7fff751fed22 xor r15d, r15d
0x7fff751fed25 mov r10d, r11d
0x7fff751fed28 mov r9d, dword ptr [0xff5ff080]
0x7fff751fed30 test r9b, 0x1
0x7fff751fed34 jnz 0x7fff1fdb4fdf
0x7fff751fed3a mov rax, qword ptr [0xff5ff0a8]
0x7fff751fed42 mov r13d, dword ptr [0xff5ff088]
0x7fff751fed4a mov qword ptr [rdi], rax
0x7fff751fed4d mov edx, dword ptr [0xff5ff088]
0x7fff751fed54 mov r14, qword ptr [0xff5ff0b0]

To me, they are quite weird. First, some of them access directly to the memory, that means some addresses, e.g. 0xff5ff080, 0xff5ff0a8 have been hard-coded into the program. Second, I find them nowhere in the loaded libraries and wget itself. Third, even more weird, by passing the parameter (IARG_MEMORYREAD_EA) to get the virtual addresses of the accessed memories. I got the addresses, e.g. 0xffffffffff5ff080, 0xffffffffff5ff0a8, etc, and all of them do not belong to the program's memory space.

Coud anyone give me some suggestions ?.

  • 1
    Do you have the opcode bytes for these instructions? What is the EIP? Is in in the wget binary itself or in one of the shared objects?
    – Igor Skochinsky
    Nov 20 '13 at 20:10
  • Thank you, but the EIP seems normal. I have edited the question to add the EIP values. These instructions are in the binary itself. Nov 20 '13 at 21:42
  • 1
    It looks like you jumped in between an instruction. Means your disassembler interprets the opcodes completely wrong. For example this can happen when you overwritten return addresses through your fuzzing.
    – samuirai
    Nov 20 '13 at 23:47
  • Thank you, I doubt that is the problem. Because before this happens, I see an indirect jump: "jmp qword ptr [rip+0x21388a]", and after several instructions, all become messy. Nov 20 '13 at 23:53
  • Unfortunately, by logging its static trace, namely before fuzzing, I see that these instructions exist. In case of you want to take a look, I give this trace here Nov 21 '13 at 0:34

This is code from the vDSO which is mapped by the kernel into every process, not from the wget binary. You could probably figure it out by inspecting the /proc/<pid>/maps file.

Here's what I have in IDA for gettimeofday from it:

.text:FFFFFFFFFF700D17   mov     rbx, 0FFFFFFFFFFDFF000h
.text:FFFFFFFFFF700D1E   lsl     r11d, eax
.text:FFFFFFFFFF700D22   xor     r15d, r15d
.text:FFFFFFFFFF700D25   mov     r10d, r11d
.text:FFFFFFFFFF700D28   mov     r9d, ds:0FFFFFFFFFF5FF080h
.text:FFFFFFFFFF700D30   test    r9b, 1
.text:FFFFFFFFFF700D34   jnz     loc_FFFFFFFFFF700FDF
.text:FFFFFFFFFF700D3A   mov     rax, ds:0FFFFFFFFFF5FF0A8h
.text:FFFFFFFFFF700D42   mov     r13d, ds:0FFFFFFFFFF5FF088h
.text:FFFFFFFFFF700D4A   mov     [rdi], rax
.text:FFFFFFFFFF700D4D   mov     edx, ds:0FFFFFFFFFF5FF088h
.text:FFFFFFFFFF700D54   mov     r14, ds:0FFFFFFFFFF5FF0B0h

So it seems PIN's disassembler chose to not sign-extend addresses (which are encoded in 4 bytes in the opcodes).

  • Thanks a lot, Igor Skochinsky, you really made my day. I have never heard about vDSO before. Nov 21 '13 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.