<div dir="ltr">Hi all,<br><br>I have kind of a strange problem. First of all, here is the short version.<br><br>My crash analysis tool<br><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bnagy_francis_tree_master_exploitaben&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=mlXFo5ZahMz-vBjZMba6HyvJwopaJXP_htINFIbYvKM&s=fqZhTBPB24o4LjP7M-vkGh9GQl7CkesFES8C4xZQypY&e=">https://github.com/bnagy/francis/tree/master/exploitaben</a> works fine on<br>OSX, but on linux it fails to correctly handle some ( but not all )<br>faulting programs. The lldb tool in the same environment and on the<br>same inputs works as expected. Ubuntu 15.04, lldb 3.6.<br><br>Here's the longer version.<br><br>I am analysing crashes (from afl-fuzz, which _may_ be involved). The<br>basic harness in exploitaben.py is a light modification of one of the<br>LLDB API example tools process_events.py. It has worked correctly for<br>many crashes on OSX, so I feel like the basic approach is sound. Here<br>are some observations.<br><br>I built the basic tests from <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jfoote_exploitable&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=mlXFo5ZahMz-vBjZMba6HyvJwopaJXP_htINFIbYvKM&s=_hNgH-j2grfNY1jxHpnI2D6VjriDp9PI3FCWzO8XZnE&e=">https://github.com/jfoote/exploitable</a>.<br>When I run, for example<br><br>exploitaben.py -- ~/src/exploitable/exploitable/tests/bin/testAbortSignal.test<br><br>I get correct output.<br><br>When I run a fault, like<br><br>exploitaben.py -- pdftoppm -r 16<br>/mnt/nfs/raid/fuzz/poppler/smoke-S1/crashes/id:000000,sig:06,src:000000,op:havoc,rep:4<br><br>I get<br><br>---<br>[ABORT] no valid frames in faulting thread<br>---<br><br>Which is my message, based on: if not<br>process.selected_thread.GetFrameAtIndex(0).IsValid()<br><br>The same test in lldb:<br><br>---<br>fuzzadmin@ebx:~/afl/poppler-0.33.0$ lldb -- pdftoppm -r 16<br>/mnt/nfs/raid/fuzz/poppler/smoke-S1/crashes/id:000000,sig:06,src:000000,op:havoc,rep:4<br>(lldb) target create "/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm"<br>Current executable set to<br>'/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm' (x86_64).<br>(lldb) settings set -- target.run-args  "-r" "16"<br>"/mnt/nfs/raid/fuzz/poppler/smoke-S1/crashes/id:000000,sig:06,src:000000,op:havoc,rep:4"<br>(lldb) run<br><br>Process 7770 launching<br>Process 7770 launched:<br>'/home/fuzzadmin/afl/poppler-0.33.0/utils/pdftoppm' (x86_64)<br>[snip many Syntax Errors]<br>Syntax Error: Pages top-level is a single Page. The document is<br>mal-formet, trying to recover...<br>Internal Error (0): Call to Object where the object was type 7, not<br>the expected type 9<br>Process 7770 stopped<br><br>* thread #1: tid = 7770, 0x00007ffff6434267 libc.so.6`gsignal + 55,<br>name = 'pdftoppm', stop reason = signal SIGABRT<br>    frame #0: 0x00007ffff6434267 libc.so.6`gsignal + 55<br>-> 0x7ffff6434267 <gsignal+55>: cmpq   $-0x1000, %rax<br>   0x7ffff643426d <gsignal+61>: ja     0x7ffff6434290            ; gsignal + 96<br>   0x7ffff643426f <gsignal+63>: rep<br>   0x7ffff6434270 <gsignal+64>: retq<br>(lldb)<br>---<br><br>I have tested the target built with vanilla gcc, vanilla clang, with<br>afl instrumentation ( see the afl project for details) and with afl +<br>clang instrumentation. None work correctly.<br><br>At the moment I am at a loss as to how to debug this issue further.<br>Does anyone have any ideas? If you would prefer to reproduce for<br>yourself, here's my environment:<br><br>poppler-0.33 built from source with ./configure --disable-shared<br>--disable-poppler-qt4 --disable-poppler-qt5<br>afl-fuzz v 1.80b<br><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bnagy_francis_tree_master_exploitaben&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=mlXFo5ZahMz-vBjZMba6HyvJwopaJXP_htINFIbYvKM&s=fqZhTBPB24o4LjP7M-vkGh9GQl7CkesFES8C4xZQypY&e=">https://github.com/bnagy/francis/tree/master/exploitaben</a><br>Python 2.7.9<br>lldb 3.6.0<br>Ubuntu 15.04<br><br>I can provide one of my crashing inputs if required. You can also find<br>me lurking on #lldb at the moment.<br><br>Cheers,<br><br>ben</div>