trace-run stop recording after `mov rax, fs:28h` instruction

[hugsy]

trace-run stop recording after `mov rax, fs:28h` instruction

[hugsy]

I'll try to reproduce.

Thanks!

[hugsy]

Hi @lieanu

Can you provide more details? I cannot reproduce the bug :

gef➤  cs greetz
0x00000000004005e0  push    rbp
0x00000000004005e1  mov rbp, rsp
0x00000000004005e4  sub rsp, 0x50
0x00000000004005e8  mov rax, qword ptr fs:[0x28]
0x00000000004005f1  mov qword ptr [rbp - 8], rax
0x00000000004005f5  mov qword ptr [rbp - 0x28], rdi
0x00000000004005f9  lea rax, qword ptr [rbp - 0x20]
[...]
gef➤  trace-run 0x40066a
[+] Tracing from 0x4005e0 to 0x40066a (max depth=1)
Hello fooo
[+] Done, logfile stored as './gef-trace-0x4005e0-0x40066a.txt'
[+] Hint: import logfile with `ida_color_gdb_trace.py` script in IDA to visualize path
gef➤  !cat ./gef-trace-0x4005e0-0x40066a.txt
#
# Execution tracing of /home/hugsy/labs/vuln-x64-canary
# Start address: 0x00000000004005e0
# End address: 0x000000000040066a
# Recursion level: 1
# automatically generated by gef.py
#

0x00000000004005e1 in greetz ()
0x00000000004005e4 in greetz ()
0x00000000004005e8 in greetz ()
0x00000000004005f1 in greetz ()
[...]
0x0000000000400669 in greetz ()
0x000000000040066a in greetz ()

[lieanu]

Binary:https://github.com/ctfs/write-ups-2015/tree/master/32c3-ctf-2015/pwn/readme-200

0x4007eb         push   rbx
0x4007ec         sub    rsp,0x118                <- $pc
0x4007f3         mov    rax,QWORD PTR fs 0x28
0x4007fc         mov    QWORD PTR [rsp+0x108],rax
0x400804         xor    eax,eax
0x400806         call   0x4006b0 <__printf_chk@plt>
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------[trace]--
#0  0x00000000004007ec in ?? ()
#1  0x0000000000000000 in ?? ()
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
gef> i-search)`trace-ru': trace-run 0x000000000040088A
[+] Tracing from 0x4007ec to 0x40088a (max depth=1)
Hello!
What's your name? a
Nice to meet you, a.
Please overwrite the flag: a
Thank you, bye!
[+] Done, logfile stored as './gef-trace-0x4007ec-0x40088a.txt'
[+] Hint: import logfile with `ida_color_gdb_trace.py` script in IDA to visualize path
gef> !cat gef-trace-0x4007ec-0x40088a.txt 
#
# Execution tracing of /mnt/hgfs/lieanu/ctf/32c3/pwn/readme/readme.bin
# Start address: 0x00000000004007ec
# End address: 0x000000000040088a
# Recursion level: 1
# automatically generated by gef.py
#

0x00000000004007f3 in ?? ()
[Inferior 1 (process 28713) exited normally]
[*] No debugging session active
#
# Execution interrupted at address 0x00000000004007f3
# Exception: The program has no registers now.
#

gef> 

[hugsy]

On Debian x64, I still cannot reproduce. I get this:

Breakpoint 1, 0x00000000004007eb in ?? ()
gef➤  trace-run 0x000000000040088A
[+] Tracing from 0x4007eb to 0x40088a (max depth=1)
Hello!
What's your name? foo
Nice to meet you, foo.
Please overwrite the flag: foo
Thank you, bye!
[+] Done, logfile stored as './gef-trace-0x4007eb-0x40088a.txt'
[+] Hint: import logfile with `ida_color_gdb_trace.py` script in IDA to visualize path
gef➤  !cat ./gef-trace-0x4007eb-0x40088a.txt
#
# Execution tracing of /home/hugsy/labs/readme/readme.bin
# Start address: 0x00000000004007eb
# End address: 0x000000000040088a
# Recursion level: 1
# automatically generated by gef.py
#

0x00000000004007ec in ?? ()
0x00000000004007f3 in ?? ()
0x00000000004007fc in ?? ()
0x0000000000400804 in ?? ()
0x0000000000400806 in ?? ()
0x00000000004006b0 in __printf_chk@plt ()
0x000000000040080b in ?? ()
0x000000000040080e in ?? ()
0x00000000004006c0 in _IO_gets@plt ()
0x0000000000400813 in ?? ()
[...]

If you do not see any exception message in your output file, it means that the command was successful. Does it work when you stepi on this instruction?

On my side, I will try on a different distro when I have a chance.

[lieanu]

@hugsy stepi works on this instr, it's a weird bug 😭

Ubuntu 14.04 x64

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty

Linux ubuntu 3.19.0-39-generic #44~14.04.1-Ubuntu SMP Wed Dec 2 10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[hugsy]

What is your version of gdb and Python ?

I cannot reproduce on latest Centos either, will try Ubuntu next.

[lieanu]

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

python 2.7 and 3.4 both failed.

[hugsy]

Ok so this is nuts, using exactly your setup (ubuntu 14.04, gdb 7.7.1-0ubuntu5~14.04.2 and python 3.4), I can reproduce it.
But no problem on 14.10 and 15.04...

Anyway, I can investigate but not sure I'll come up with a clean solution.

[hugsy]

I spent wayyy too long looking for a rational explanation for it not to work in vain. The problem comes from gdb Python API, not gef.

I would recommend that either you start tracing after the 04007F3 mov rax, fs:28h or even better upgrade your gdb & gdb-python.

If you can come up with a clean workaround, re-open and post it here. I'll be happy to integrate it.

Cheers