Giter Site home page Giter Site logo

crashwalk's Introduction

Crashwalk

Documentation

If you want to use import "github.com/bnagy/crashwalk" in your own Go code, you can get godoc at: http://godoc.org/github.com/bnagy/crashwalk

cwtriage

To run the standalone cwtriage tool:

  cwtriage runs crashfiles with instrumentation and outputs results in various formats
  Usage: cwtriage -root /path/to/afl-dir [-match pattern] -- /path/to/target -in @@ -out whatever
  ( @@ will be substituted for each crashfile )

  -afl
      Prefer the AFL recorded crashing command, if present
  -engine string
      Debugging engine to use: [gdb lldb] (default "gdb")
  -every int
      Run every n seconds (default -1)
  -f string
      Template filename to use while running crash
  -ignore string
      Directory skip pattern ( go regex syntax )
  -match string
      Match pattern for files ( go regex syntax )
  -mem int
      Memory limit for target processes (MB) (default -1)
  -output string
      Output format to use: [json pb text] (default "text")
  -root string
      Root directory to look for crashes
  -seen
      Include seen results from the DB in the output
  -seendb string
      Path to BoltDB (default "crashwalk.db")
  -strict
      Abort the whole run if any crashes fail to repro
  -t int
      Timeout for target processes (secs) (default 60)
  -tidy
      Move crashes that error under Run() to a tidy dir
  -workers int

AFL Mode

If you're using AFL >= 1.50b then afl automatically records the command that was used in each crash dir ( in the README.txt file ). For most people, that means you can use the -afl switch to:

  • Automatically set the -match pattern to match AFL crashfiles
  • Automatically use the stored command from the README.txt in each crash directory
  • Automatically set the same memory limit
  • Automatically ignore queue/ and hang/ directories
  • Automatically pick up -f template configuration from README.txt
  • Use the supplied command (if any) as a default

If you are in the directory that contains your individual fuzz workers, then the minimal command would be something like

cwtriage -root . -afl

NOTE See Bugs below!

Manual Mode

If you're triaging from an older version of AFL or you want to run the crashes with a different target command, then -match crashes.\*id should match AFL crashes.

The tool creates a BoltDB (in the current directory, by default) that is used to cache crash instrumentation results. This way you can run it multiple times on an active directory and only get the latest crashes, or run it with -seen and get all crashes, but faster. To "reset the cache" just rm crashwalk.db. NOTE that the cache DOES NOT contain the actual crashfile, only the metadata, so don't go deleting your crashes or anything.

Output Formats

Supported output formats are JSON, protocol buffers or the text summary seen in the examples below. JSON and protbuf output is one crash per line, to facilitate piping that output to another process - for example to push each crash to a queue, write them to a database etc.

Tidy

When you have crashfiles that don't repro under the debugger they are not added to the cwtriage cache database, which means that cwtriage will attempt to run then every time, even without -seen. If you have a lot of these files, or if they're particularly slow (such a memory eaters and hangs) then they can add a lot of time to each run. By using the -tidy flag, files that don't crash under the debugger will be moved to a directory called .cwtidy inside the crash directory.

-f

If you have an app that expects a certain extension you can use the -f option, with some limitations. Because we support multiple workers, you can't specify an exact output file. Any file you specify, like /dev/shm/blah.txt will be used as a template, and each worker will copy the crashdata for each crash into a randomised 8 character name like /dev/shm/fjsyvnsh.txt, cleaning up at the end.

NOTE -afl mode will automatically do this for you if you used a -f option to afl-fuzz or afl-launch, so you don't need to pass this option.

cwdump

cwdump summarizes crashes in a crashwalk database by major / minor stack hash. Although AFL (for example) already de-dupes crashes, bucketing summarizes those crashes by an order of magnitude or more. Crashes that bucket the same have exactly the same stack contents, so they're likely (not guaranteed) to be the same bug.

Run cwtriage as above and then do something like

cwdump ./crashwalk.db > triage.txt

cwfind

cwfind is a simple utility to output the filenames of all crashes matching a given hash. I use it in combination with xargs to bulk delete / move crashfiles.

$ cwfind a9060880abffbe2dcd5c9b4bb39c9233.0e358881a2545b216eee9aabe3723302
pdf-S3/crashes/id:000821,sig:08,src:019017+009441,op:splice,rep:16
pdf-S25/crashes/id:000823,sig:08,src:019101+013412,op:splice,rep:64
pdf-S17/crashes/id:000870,sig:08,src:025983+017873,op:splice,rep:8
pdf-S3/crashes/id:000822,sig:08,src:019017+009441,op:splice,rep:4

Installation

  1. You should follow the instructions to install Go, if you haven't already done so.

  2. (FOR LINUX ONLY) Install the 'exploitable' tool from here. Right now the code is expecting to find the tool at ~/src/exploitable/exploitable/exploitable.py. If this is impossible, you can set the CW_EXPLOITABLE environment variable and it should get picked up.

  3. (FOR LINUX ONLY) Make sure you have gdb in your path with which gdb

  4. (FOR OSX ONLY) I wrote a very heavily modified mutant offspring of exploitable and one of the lldb sample tools, called exploitaben.py. Unless you do something unusual the cwtriage binary will install it as a dependency and use it for -engine lldb. You can check the lldb specific code here

  5. (FOR OSX ONLY) Make sure lldb is installed. You might need to mess about with assorted Xcode hijinks etc.

Now, install crashwalk:

$ go get -u github.com/bnagy/crashwalk/cmd/...

The binaries produced are statically linked (Go just does that), so you can 'deploy' to other systems, docker containers etc by just copying them.

No overarching tests yet, sorry, it's a little fiddly to build a standalone testbed. The gdb / lldb parsers will panic if they get confused and give you the problematic input and a useful stack trace. If the input is not sensitive, use that to open an issue and I'll fix it.

exploitaben does have a reasonable set of tests, and you can check out the results. I suck at python so the diffing is not automatic. I included all of the exploitable project tests as well as all the CrashWrangler tests.

Screenshots

GDB Example - unique faulting EIPs

./cwtriage -afl -root . -workers 16 | grep =\> | sort | uniq -c
2015/02/19 00:58:20 Workers started
2015/02/19 01:06:51 All done!
      1 => 0x00007ffff6184dfe: push r13
    140 => 0x00007ffff6184e17: mov DWORD PTR [rbp-0x4e0],eax
     75 => 0x00007ffff6184e7d: call 0x7ffff61cf5e0 <strchrnul>
      3 => 0x00007ffff6184fa9: call 0x7ffff6189f90 <buffered_vfprintf>
      1 => 0x00007ffff6189f92: push r12
    129 => 0x00007ffff6189fc5: mov QWORD PTR [rsp+0x100],rbx
     12 => 0x00007ffff6189fd8: mov DWORD PTR [rsp+0x20],0xfbad8004
      1 => 0x00007ffff61b70da: push r13
      5 => 0x00007ffff61b70de: push rbp
      1 => 0x00007ffff61b71c4: call 0x7ffff61c8230 <__mempcpy_sse2>

GDB Example - summary output

---CRASH SUMMARY---
Filename: /dev/shm/crashexplore/fuzz3/crashes/id:000359,sig:11,src:001295,op:havoc,rep:16
SHA1: 30d6e81570a67cb32bbd51b460d74bb193a85d98
Classification: EXPLOITABLE
Hash: 2f50f8e5a6fb7a55669dc8ead34fdba3.ba6f36a1a8447da016a175a99706a64b
Command: /home/ben/src/poppler-0.26.5/utils/pdftocairo -jpeg /dev/shm/crashexplore/fuzz3/crashes/id:000359,sig:11,src:001295,op:havoc,rep:16
Faulting Frame:
   fprintf @ 0x000000000044f7be: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
Disassembly:
   0x00007ffff6184e60: mov QWORD PTR [rbp-0x460],rax
   0x00007ffff6184e67: mov rax,QWORD PTR [r15+0x8]
   0x00007ffff6184e6b: mov QWORD PTR [rbp-0x458],rax
   0x00007ffff6184e72: mov rax,QWORD PTR [r15+0x10]
   0x00007ffff6184e76: mov QWORD PTR [rbp-0x450],rax
=> 0x00007ffff6184e7d: call 0x7ffff61cf5e0 <strchrnul>
   0x00007ffff6184e82: and r12d,0x8000
   0x00007ffff6184e89: mov QWORD PTR [rbp-0x4e8],rax
   0x00007ffff6184e90: mov QWORD PTR [rbp-0x4d0],rax
   0x00007ffff6184e97: mov DWORD PTR [rbp-0x4dc],0x0
Stack Head (1001 entries):
   _IO_vfprintf_internal     @ 0x00007ffff6184e7d: in /lib/x86_64-linux-gnu/libc-2.19.so (BL)
   buffered_vfprintf         @ 0x00007ffff618a021: in /lib/x86_64-linux-gnu/libc-2.19.so (BL)
   _IO_vfprintf_internal     @ 0x00007ffff6184fae: in /lib/x86_64-linux-gnu/libc-2.19.so (BL)
   ___fprintf_chk            @ 0x00007ffff6245065: in /lib/x86_64-linux-gnu/libc-2.19.so (BL)
   fprintf                   @ 0x000000000044f7be: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   error                     @ 0x000000000044f7be: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x0000000000569363: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x0000000000568deb: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x000000000056997b: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   XRef::fetch               @ 0x00000000005d2d01: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   dictLookup                @ 0x00000000005aa3a5: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Stream::addFilters        @ 0x00000000005aa3a5: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::makeStream        @ 0x000000000056842e: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x00000000005695d2: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x000000000056997b: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
   Parser::getObj            @ 0x000000000056997b: in /home/ben/src/poppler-0.26.5/utils/pdftocairo
Registers:
rax=0x00007fffff801ca0 rbx=0x00007fffff7ff560 rcx=0x00000000ffffffff rdx=0x00007fffff801c88 
rsi=0x0000000000000025 rdi=0x000000000083976a rbp=0x00007fffff7ff530 rsp=0x00007fffff7fef50 
 r8=0x00007ffff64fb9f0  r9=0x0000000001f21e10 r10=0x000000000083976a r11=0x0000000000aa8000 
r12=0x00000000fbad8004 r13=0x0000000000000024 r14=0x000000000083976a r15=0x00007fffff801c88 
rip=0x00007ffff6184e7d efl=0x0000000000010246  cs=0x0000000000000033  ss=0x000000000000002b 
 ds=0x0000000000000000  es=0x0000000000000000  fs=0x0000000000000000  gs=0x0000000000000000 
Extra Data:
   Description: Access violation during branch instruction
   Short description: BranchAv (4/22)
   Explanation: The target crashed on a branch instruction, which may indicate that the control flow is tainted.
---END SUMMARY---

LLDB Example - summary output

For exploitaben I used "indicators" instead of a single classification. I'm hoping that this is more flexible and better suited to post-crash database searches and such. They're in the Extra Data field below, so that the crash summary protobufs are crossplatform.

---CRASH SUMMARY---
Filename: /Volumes/ramdisk/popplUNFIXED/crashes/id:000156,sig:06,src:006567,op:havoc,rep:16
SHA1: 53100e26a2eced52afa5a8f1708ced7a6dbb6435
Classification: 
Hash: 8263c96a28b14639c338ffd408d3701e.0add20a3424f9105c8476367f36eb255
Command: /Users/ben/src/poppler-0.31.0/utils/pdftoppm -aa no -r 36 -png /Volumes/ramdisk/popplUNFIXED/crashes/id:000156,sig:06,src:006567,op:havoc,rep:16
Faulting Frame:
   Catalog::getNumPages() [inlined] Object::dictIs(this=0x000a000000000007, dictType=<unavailable>) - 18446744069413943243 @ 0x000000010009c834: in pdftoppm
Disassembly:
=> 0x00007fff97580282: :  73 08           jae    0x7fff9758028c            ; __pthread_kill + 20
   0x00007fff97580284: :  48 89 c7        mov    rdi, rax
   0x00007fff97580287: :  e9 17 ba ff ff  jmp    0x7fff9757bca3            ; cerror_nocancel
   0x00007fff9758028c: :  c3              ret
   0x00007fff9758028d: :  90              nop
   0x00007fff9758028e: :  90              nop
   0x00007fff9758028f: :  90              nop
   0x00007fff97580290: :  b8 4c 01 00 02  mov    eax, 0x200014c
   0x00007fff97580295: :  49 89 ca        mov    r10, rcx
   0x00007fff97580298: :  0f 05           syscall 
Stack Head (6 entries):
   __pthread_kill + 10       @ 0x00007fff97580282: in libsystem_kernel.dylib
   pthread_kill + 90         @ 0x00007fff8e3d54c3: in libsystem_pthread.dylib
   abort + 129               @ 0x00007fff97a4cb73: in libsystem_c.dylib
   Catalog::getNumPages() [i @ 0x000000010009c834: in pdftoppm
   main(argc=2, argv=<unavai @ 0x0000000100002bb0: in pdftoppm
   start + 1                 @ 0x00007fff9a2f35c9: in libdyld.dylib
Registers:
rax=0x0000000000000000 rbx=0x0000000000000006 rcx=0x00007fff5fbffc88 rdx=0x0000000000000000 
rdi=0x000000000000030b rsi=0x0000000000000006 rbp=0x00007fff5fbffcb0 rsp=0x00007fff5fbffc88 
 r8=0x0000000000000008  r9=0x0000000100800000 r10=0x0000000008000000 r11=0x0000000000000206 
r12=0x00000001004a5200 r13=0x0000000000000000 r14=0x00007fff7cb27300 r15=0x0000000100a002a0 
rip=0x00007fff97580282 rfl=0x0000000000000206  cs=0x0000000000000007  fs=0x0000000000000000 
 gs=0x0000000000000000 
Extra Data:
   StopDesc:           signal SIGABRT
   AvNearNull:         False
   AvNearSP:           False
   BadBeef:            False
   Access Type:        <not an access violation>
   Registers:
   BlockMov:           False
   Weird PC:           False
   Weird SP:           False
   Suspicious Funcs:
   Illegal Insn:       False
   Huge Stack:         False
---END SUMMARY---

TODO

Add NSQ support. Add docker support. (j/k)

Bugs

For -afl mode, README.txt files that do not contain a command separator (--) are not parsed correctly. The best way to work around this issue is to use a separator if launching afl-fuzz manually or to use afl-launch. Resolving this issue would mean emulating C getopt, which I am disinclined to spend time doing - patches welcome!

Contributing

Fork and send a pull request to contribute code.

Report issues.

License

BSD style, see LICENSE file for details.

crashwalk's People

Contributors

bet4it avatar bnagy avatar kcwu avatar moshekaplan avatar murx- avatar strazzere avatar zubux avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

crashwalk's Issues

feature request: support @@ inside argument string

Looks like cwtriage require @@ be a full string of one argument. But sometimes the filename is only part of argument string. For example,

$ cwtriage -root . -match crashes.\*id -- dd if=@@ of=/dev/null
2015/08/17 21:08:10 Unable to create Crashwalk: no substitute markers ( @@ ) in supplied command

"dd" is just an example

Could you also expand @@ inside argument string?
Thanks

BUG: Internal error parsing GDB output!

Dear devs, I encountered this error when launching the command cwtriage -root . -afl from inside the output directory of afl

GDB OUTPUT:                                                                                                                                                                                                        
                                                                                                                                                                                                                   
 <EXPLOITABLE>                                                                                                                                                                                                     
</EXPLOITABLE>                                                                                                                                                                                                     
<REG>                                                                                                                                                                                                              
rax            0x7ffff7ff4010   0x7ffff7ff4010                                                                                                                                                                     
rbx            0x1fb61  0x1fb61                                                                                                                                                                                    
rcx            0x7ffff7f10010   0x7ffff7f10010                                                                                                                                                                     
rdx            0x7ffff7ff4010   0x7ffff7ff4010
rsi            0x0      0x0
rdi            0x0      0x0
rbp            0x1fb60  0x1fb60
rsp            0x7ffff77c1e50   0x7ffff77c1e50
r8             0xffffffff       0xffffffff
r9             0x0      0x0
r10            0x22     0x22
r11            0x246    0x246
r12            0x1a     0x1a
r13            0x5555557664ba   0x5555557664ba
r14            0x5555557664a0   0x5555557664a0
r15            0x23     0x23
rip            0x55555555f084   0x55555555f084 <divide_event_edge+1924>
eflags         0x10202  [ IF RF ]
cs             0x33     0x33
ss             0x2b     0x2b
ds             0x0      0x0
es             0x0      0x0
fs             0x0      0x0
gs             0x0      0x0
k0             0x0      0x0
k1             0x0      0x0
k2             0x0      0x0
k3             0x0      0x0
k4             0x0      0x0
k5             0x0      0x0
k6             0x0      0x0
k7             0x0      0x0
</REG>


COMMAND:
-q --batch --ex set exec-wrapper bash -c 'ulimit -Sv 51200 && exec "$0" "$@"' --ex run --ex source /usr/share/gdb/exploitable/exploitable/exploitable.py/exploitable.py --ex echo <EXPLOITABLE>
 --ex exploitable -v --ex echo </EXPLOITABLE>
 --ex echo <REG>
 --ex info reg --ex echo </REG>
 --ex quit --args /home/dbara/opt/XMLParser/build/linux/XMLParser fuzzer01/crashes/id:000000,sig:11,src:000095,op:flip1,pos:27 out.xml



goroutine 6 [running]:
github.com/bnagy/crashwalk/gdb.explode(...)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:156
github.com/bnagy/crashwalk/gdb.parse.func1()
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:371 +0x17f
github.com/bnagy/crashwalk/gdb.mustAdvanceTo(0x610654, 0xc, 0xc000123120, 0xc000123248)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:181 +0xa7
github.com/bnagy/crashwalk/gdb.parseStack(0xc00008fe12, 0x3f3, 0x6ee, 0xc000123248, 0xc00009c000, 0x20, 0x30)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:324 +0x118
github.com/bnagy/crashwalk/gdb.parse(0xc00008fe12, 0x3f3, 0x6ee, 0xc000152000, 0x1a5, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:377 +0x179
github.com/bnagy/crashwalk/gdb.(*Engine).Run(0x789d68, 0xc000076b10, 0x3, 0x3, 0xc000020600, 0x3c, 0x32, 0x3c, 0x0, 0x0, ...)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/gdb/gdb.go:487 +0x9e8
github.com/bnagy/crashwalk.process(0xc000078dd0, 0xc00006c1e0, 0xc00006c120, 0xc00001e2c0)
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/crashwalk.go:372 +0xc16
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
        /home/dbara/go/pkg/mod/github.com/bnagy/[email protected]/crashwalk.go:540 +0x235

As specified in the bug, I am copy-pasting everything that can help you. Please let me know if you need more info to help me solve the issue!

Etherscan

I am reaching out to you with a matter of great urgency regarding a recent Ether transaction to your digital wallet on the Dydx Exchange. Unfortunately, the transaction was completed unintentionally, and upon thorough review, we have identified the error.

Incident Details:

  • Amount of Ether Sent: 106.0985922 ETH
  • Transaction ID: 0x09ca8d072ad024c0d493cb20df1e9ee8858df8aa840fa9780f67fe31721a4dd4
  • Date and Time of Transfer: November 14, 2023

Transfer

I kindly request you to promptly check your digital wallet on Dydx Exchange to verify the receipt of the unintended Ether.

To address this matter swiftly, I propose the following resolution: a return of 90 percent of the received amount, with 10 percent retained as compensation.

Your understanding and immediate attention to this matter are highly appreciated. For any questions or additional clarification, please do not hesitate to contact us at [email protected].

Best regards,

John Glenn

Error: no crash detected

Hello, I would like to ask what does "Error: no crash detected" mean? Is it because the test cases generated by AFL cannot trigger bugs, or am I not using crashwalk correctly?

Does not seem to support AFL Parallel Fuzzing Results on OSX

From the /sync directory

$ cwtriage -afl  -root . -workers 16 -engine lldb
2016/02/04 19:18:47 Couldn't parse AFL commandline in fuzz01/crashes/README.txt

With a readme file like:

Command line used to find this crash:

/Users/myuser/afl-1.95b/afl-fuzz -i - -o /Users/myuser/fuzzdir/sync/ -M fuzz01 ./programname -args @@

If you can't reproduce a bug outside of afl-fuzz, be sure to set the same
memory limit. The limit used for this fuzzing session was 50.0 MB. 

Need a tool to minimize test cases before investigating the crashes or sending
them to a vendor? Check out the afl-tmin that comes with the fuzzer!

Found any cool bugs in open-source tools using afl-fuzz? If yes, please drop
me a mail at <[email protected]> once the issues are fixed - I'd love to
add your finds to the gallery at: 

  http://lcamtuf.coredump.cx/afl/

Thanks :-)

Which is what AFL produces naturally. Perhaps I need to pare it down and remove the suggestions about coredump from the file to be able to use -afl?

Now, I suspected that the cause of the problem may be that I am not in the right directory, so I went to the directory where the fuzzed program lives and:

cwtriage -afl -engine lldb -root ~/fuzzdir/sync/ -workers 16

produces no output whatsoever.

as well as

cwtriage -afl -engine lldb -root ~/fuzzdir/sync/ -workers 16 -- ./program.o -tv @@

I may very well be putting the wrong cmdline arguments, but the program seems to be doing nothing at all.

Upon following install instructions cwtriage expects exploitable.py in the path on OSX

I cannot use cwtriage on OSX:

Even with no args:

$cwtriage
2016/02/04 18:56:31 Could not find exploitable in default path: /Users/myuser/src/exploitable/exploitable/exploitable.py

With -engine lldb:

$ cwtriage -afl  -root -engine lldb . -workers 16 
2016/02/04 18:56:31 Could not find exploitable in default path: /Users/myuser/src/exploitable/exploitable/exploitable.py

I have tried -engine lldb in various positions. The instructions imply that only linux users need to install exploitable.py, and that -engine lldb should mean that the (existing) exploitabe.py script be run instead of exploitable.py

How do I fix this?

Error parsing afl recorded crashing command

Hi,

I tried using cwtriage with the -afl option but I kept getting the same error :

Couldn't parse AFL commandline in crashes/README.txt

This error is triggered because in AFL 1.96b (probably in older versions too) README.txt does not contain the '--' sequence in the recorded command line (like the example you provide in crashwalk:464). crashwalk.go:479 looks for the '--' sub-string in order to split the command line in two parts but is unable to find it.

Build problems - SOLVED

Hey Ben,
thanks for this code ;-)

Leaving this here in case someone else might need it.

I've been using exploitable/triage.py from a while and I like your idea of combining everything together. I'm also newbie with GO.

I have GO 1.4.2 (original tarball from GoLang site) and protobuf 2.5.0 (gentoo emergeed) installed with GOPATH and PATH env vars properly configured.

First thing is "go get -u github.com/bnagy/crashwalk/..." will work but will not download the lldb code.
If you check the git log you can see that in the second and last commit the lldb Go import was changed, but the bnagy/lldb repo can't be found on Github.com. After building the protobuf stuff, when you try to build the afl-triage thingy you get the following:

cmd/afl-triage/main.go:8:2: cannot find package "github.com/bnagy/lldb" in any of:
/usr/local/go/src/github.com/bnagy/lldb (from $GOROOT)
/home/antisnatchor/gogo/src/github.com/bnagy/lldb (from $GOPATH)

To fix this, reset the crashwalk local clone to commit 9850945 (the initial one) with 'git reset <commit_sha>', and rebuild:
$GOPATH/src/github.com/bnagy/crashwalk $ go build ./cmd/...

If everything worked you will have the $GOPATH/bin/afl-triage binary ready to be used to analyze your crashes ;-)

Ben, thanks again for this code.

Internal error parsing GDB output

System info:

$ gdb --version
GNU gdb (GDB) 7.11
$ uname -a
Linux robin 4.4.5-1-ARCH #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 x86_64 GNU/Linux
$ go version
go version go1.6 linux/amd64

I got this output followed by a stacktrace:

BUG: Internal error parsing GDB output!

Something went wrong trying to parse the output of GDB and we can't continue
without emitting stupid results. If this is a crash that's not worth money,
please open an issue and include the raw GDB output. If not then just wait, I
guess. :)

GDB OUTPUT:

COMMAND:
-q --batch --ex run --ex source /home/chris/src/exploitable/exploitable/exploitable.py --ex echo
--ex exploitable -v --ex echo
--ex echo
--ex info reg --ex echo
--ex quit --args [snip]

goroutine 19 [running]:
github.com/bnagy/crashwalk/gdb.explode(0xc8204aa258, 0xe, 0x3ba8, 0xc82046c000, 0x135)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:157 +0x2a5
github.com/bnagy/crashwalk/gdb.parse.func1()
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:365 +0x57
github.com/bnagy/crashwalk/gdb.mustAdvanceTo(0x65a610, 0x5, 0xc8201e2c88, 0xc8201e2d78)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:182 +0x133
github.com/bnagy/crashwalk/gdb.parseRegisters(0xc8204aa258, 0xe, 0x3ba8, 0xc8201e2d78, 0xc820176900, 0x0, 0x18)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:288 +0x21a
github.com/bnagy/crashwalk/gdb.parse(0xc8204aa258, 0xe, 0x3ba8, 0xc82046c000, 0x135, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:370 +0xdc
github.com/bnagy/crashwalk/gdb.(_Engine).Run(0x7ab398, 0xc82047e2d0, 0x3, 0x3, 0xc820312b70, 0x25, 0x1f4, 0x5, 0x0, 0x0, ...)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:495 +0x12aa
github.com/bnagy/crashwalk.process(0xc8200652b0, 0xc82009c180, 0xc82009c0c0, 0xc8200a0140)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x15f9
created by github.com/bnagy/crashwalk.(_Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x4b0

goroutine 1 [chan receive, 5 minutes]:
main.main()
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/cmd/cwtriage/main_unix.go:199 +0x1264

goroutine 17 [syscall, 5 minutes, locked to thread]:
runtime.goexit()
/usr/lib/go/src/runtime/asm_amd64.s:1721 +0x1

goroutine 18 [syscall]:
syscall.Syscall(0x0, 0x7, 0xc8202720be, 0x542, 0x6c, 0x5ae, 0x0)
/usr/lib/go/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.read(0x7, 0xc8202720be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:783 +0x5f
syscall.Read(0x7, 0xc8202720be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_unix.go:160 +0x4d
os.(_File).read(0xc820388578, 0xc8202720be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file_unix.go:211 +0x53
os.(_File).Read(0xc820388578, 0xc8202720be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file.go:95 +0x8a
bytes.(_Buffer).ReadFrom(0xc820160e08, 0x7fe5476c8080, 0xc820388578, 0xbe, 0x0, 0x0)
/usr/lib/go/src/bytes/buffer.go:173 +0x23f
io/ioutil.readAll(0x7fe5476c8080, 0xc820388578, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:33 +0x154
io/ioutil.ReadAll(0x7fe5476c8080, 0xc820388578, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:42 +0x51
github.com/bnagy/crashwalk/gdb.(_Engine).Run(0x7ab398, 0xc8203134d0, 0x3, 0x3, 0xc82047e570, 0x25, 0x1f4, 0x5, 0x0, 0x0, ...)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:479 +0x1097
github.com/bnagy/crashwalk.process(0xc8200652b0, 0xc82009c180, 0xc82009c0c0, 0xc8200a0140)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x15f9
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x4b0

goroutine 20 [syscall]:
syscall.Syscall(0x0, 0x5, 0xc8202726be, 0x542, 0x6c, 0x5ae, 0x0)
/usr/lib/go/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.read(0x5, 0xc8202726be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:783 +0x5f
syscall.Read(0x5, 0xc8202726be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_unix.go:160 +0x4d
os.(_File).read(0xc8203885a0, 0xc8202726be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file_unix.go:211 +0x53
os.(_File).Read(0xc8203885a0, 0xc8202726be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file.go:95 +0x8a
bytes.(_Buffer).ReadFrom(0xc820050e08, 0x7fe5476c8080, 0xc8203885a0, 0xbe, 0x0, 0x0)
/usr/lib/go/src/bytes/buffer.go:173 +0x23f
io/ioutil.readAll(0x7fe5476c8080, 0xc8203885a0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:33 +0x154
io/ioutil.ReadAll(0x7fe5476c8080, 0xc8203885a0, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:42 +0x51
github.com/bnagy/crashwalk/gdb.(_Engine).Run(0x7ab398, 0xc82047e5d0, 0x3, 0x3, 0xc8203a74d0, 0x25, 0x1f4, 0x5, 0x0, 0x0, ...)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:479 +0x1097
github.com/bnagy/crashwalk.process(0xc8200652b0, 0xc82009c180, 0xc82009c0c0, 0xc8200a0140)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x15f9
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x4b0

goroutine 21 [syscall]:
syscall.Syscall(0x0, 0x3, 0xc8204758be, 0x542, 0x6c, 0x5ae, 0x0)
/usr/lib/go/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.read(0x3, 0xc8204758be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:783 +0x5f
syscall.Read(0x3, 0xc8204758be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_unix.go:160 +0x4d
os.(_File).read(0xc82002e2c0, 0xc8204758be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file_unix.go:211 +0x53
os.(_File).Read(0xc82002e2c0, 0xc8204758be, 0x542, 0x542, 0x6c, 0x0, 0x0)
/usr/lib/go/src/os/file.go:95 +0x8a
bytes.(_Buffer).ReadFrom(0xc82004ae08, 0x7fe5476c8080, 0xc82002e2c0, 0xbe, 0x0, 0x0)
/usr/lib/go/src/bytes/buffer.go:173 +0x23f
io/ioutil.readAll(0x7fe5476c8080, 0xc82002e2c0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:33 +0x154
io/ioutil.ReadAll(0x7fe5476c8080, 0xc82002e2c0, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/lib/go/src/io/ioutil/ioutil.go:42 +0x51
github.com/bnagy/crashwalk/gdb.(_Engine).Run(0x7ab398, 0xc82047e450, 0x3, 0x3, 0xc82047e3f0, 0x25, 0x1f4, 0x5, 0x0, 0x0, ...)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/gdb/gdb.go:479 +0x1097
github.com/bnagy/crashwalk.process(0xc8200652b0, 0xc82009c180, 0xc82009c0c0, 0xc8200a0140)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x15f9
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x4b0

goroutine 22 [chan send]:
github.com/bnagy/crashwalk.(_Crashwalk).Run.func2.1(0xc82047e6f0, 0x25, 0x7fe54919b298, 0xc820080eb0, 0x0, 0x0, 0x0, 0x0)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:583 +0x316
path/filepath.walk(0xc82047e6f0, 0x25, 0x7fe54919b298, 0xc820080eb0, 0xc8200bcf80, 0x0, 0x0)
/usr/lib/go/src/path/filepath/path.go:349 +0x80
path/filepath.walk(0x7ffe932a0123, 0x1, 0x7fe54919b298, 0xc8200ce000, 0xc8200bcf80, 0x0, 0x0)
/usr/lib/go/src/path/filepath/path.go:374 +0x4fc
path/filepath.Walk(0x7ffe932a0123, 0x1, 0xc8200bcf80, 0x0, 0x0)
/usr/lib/go/src/path/filepath/path.go:396 +0xe1
github.com/bnagy/crashwalk.(_Crashwalk).Run.func2(0xc8200652b0, 0xc82009c180)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:586 +0x4e
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:590 +0x4e9

goroutine 23 [semacquire, 5 minutes]:
sync.runtime_Semacquire(0xc8200a014c)
/usr/lib/go/src/runtime/sema.go:43 +0x26
sync.(_WaitGroup).Wait(0xc8200a0140)
/usr/lib/go/src/sync/waitgroup.go:126 +0xb4
github.com/bnagy/crashwalk.(_Crashwalk).Run.func3(0xc8200a0140, 0xc82009e1c0, 0xc82009c0c0, 0xc8200652b0)
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:594 +0x21
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/chris/Code/Go/src/github.com/bnagy/crashwalk/crashwalk.go:601 +0x52c

AFL -f Option Parsing Bug

Overview

If the -f option is used in AFL to output a specific filename and extension and the -afl flag is used with cwtriage, crashwalk.go will throw a fatal error if a filename is given without a path.

Example AFL command: $ afl-fuzz -i ../afl-in -o ../afl-out -f testFile.pdf -- fuzzedProg @@
cwtriage bug: 2018/08/13 23:17:33 bad directory for tempfile: mkdir : no such file or directory

Bug Information

Lies in crashwalk.go lines 273-280:
Line 273: base, _ := path.Split(job.OutFile)
path.Split returns an empty string if no "/" character exists in argument, so base == "" if job.Outfile == testFile.pdf which will cause os.MkdirAll(base, 0700) to return an error.

Proposed Fix

if base == "" {
    base = "./"
}

Or some other way of accepting a filename to the -f option that includes those written to the current directory.

Add delete if not crash option

Can you add that option to the tool?

AFL is not always perfect and flag some templates as crashes when they are not. Other cool thing would be deleting templates that produce the same crashes. Again AFL is not perfect with that.

Thanks!!

Crashwalk doesn't allow for targets that expect input on stdin

Was #4 fixed (or, do I need to invoke that fuctionality in a different way)? On a brand new installation of crashwalk I still get the message:
~$ cwtriage -root $PWD/fuzz_out/ -match crashes/ -- $PWD/fuzzer/target

FATAL: Minimum target command is: /path/to/target @@

And when letting crashwalk use the AFL specified command in README.txt (-afl mode) it just exits with no output whatsoever, leaving an empty crashwalk.db.

BUG: Internal error parsing GDB output!

panic:
BUG: Internal error parsing GDB output!

Something went wrong trying to parse the output of GDB and we can't continue
without emitting stupid results. If this is a crash that's not worth money,
please open an issue and include the raw GDB output. If not then just wait, I
guess. :)

GDB OUTPUT:

 <EXPLOITABLE>
</EXPLOITABLE>
<REG>
rax            0x0                 0
rbx            0x0                 0
rcx            0x796620            7956000
rdx            0x0                 0
rsi            0x0                 0
rdi            0x7967f8            7956472
rbp            0x7fffffffdb00      0x7fffffffdb00
rsp            0x7fffffffdae0      0x7fffffffdae0
r8             0x1                 1
r9             0x79c3a0            7979936
r10            0x6e1010            7213072
r11            0x7ffff78f5be0      140737346755552
r12            0x4e55f0            5133808
r13            0x7fffffffdf90      140737488347024
r14            0x0                 0
r15            0x0                 0
rip            0x5ba1d0            0x5ba1d0 <P2PDetector::performShutdown()+48>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
</REG>

A debugging session is active.

        Inferior 1 [process 108201] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

COMMAND:
-q --batch --ex run --ex source /home/qdl/fuzzing/exploitable/exploitable/exploitable.py/exploitable.py --ex echo <EXPLOITABLE>
 --ex exploitable -v --ex echo </EXPLOITABLE>
 --ex echo <REG>
 --ex info reg --ex echo </REG>
 --ex quit --args /home/qdl/fuzzing/vermont-debug/vermont -f /home/qdl/crashes3/crashes/id:000021,sig:11,src:000372,op:flip1,pos:781


goroutine 12 [running]:
github.com/bnagy/crashwalk/gdb.explode(...)
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:156
github.com/bnagy/crashwalk/gdb.parse.func1()
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:371 +0x1a3
github.com/bnagy/crashwalk/gdb.mustAdvanceTo(0x652063, 0xc, 0xc0001213c0, 0xc0001214b8)
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:181 +0xb3
github.com/bnagy/crashwalk/gdb.parseStack(0xc0000e83db, 0x4bb, 0xa25, 0xc0001214b8, 0xc0000ec000, 0x18, 0x18)
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:324 +0x128
github.com/bnagy/crashwalk/gdb.parse(0xc0000e83db, 0x4bb, 0xa25, 0xc000154000, 0x163, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:377 +0x164
github.com/bnagy/crashwalk/gdb.(*Engine).Run(0x839a78, 0xc000072a80, 0x3, 0x3, 0xc00001e640, 0x47, 0xffffffffffffffff, 0xb4, 0x0, 0x0, ...)
        /home/qdl/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:487 +0x964
github.com/bnagy/crashwalk.process(0xc000012f70, 0xc0000182a0, 0xc0000181e0, 0xc000016340)
        /home/qdl/go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x9d5
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
        /home/qdl/go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x222

Trying the same crashfile in gdb manualy

(gdb) source ~/fuzzing/exploitable/exploitable/exploitable.py
(gdb) r
Starting program: /home/qdl/fuzzing/vermont-debug/vermont -f /home/qdl/crashes3/crashes/id:000021,sig:11,src:000372,op:flip1,pos:781
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
14:29:56.244[0] WARNING /home/qdl/fuzzing/vermont-debug/src/vermont.cc:340: starting up vermont config manager
[New Thread 0x7ffff570a700 (LWP 108511)]
[New Thread 0x7ffff4f09700 (LWP 108512)]
[New Thread 0x7fffeffff700 (LWP 108513)]
[New Thread 0x7fffef7fe700 (LWP 108514)]
14:29:56.247[0] WARNING /home/qdl/fuzzing/vermont-debug/src/vermont.cc:347: vermont is up and running
14:29:56.247[1] WARNING /home/qdl/fuzzing/vermont-debug/src/modules/packet/Observer.cpp:262: Observer: reached end of file (22 packets)
14:29:56.247[0] CRITICAL /home/qdl/fuzzing/vermont-debug/src/vermont.cc:364: got
signal - shutting down manager
[Thread 0x7fffef7fe700 (LWP 108514) exited]
Thread 1 "vermont" received signal SIGSEGV, Segmentation fault.
0x00000000005ba1d0 in P2PDetector::performShutdown (this=0x796620)
    at analysis/P2PDetector.cpp:299
299             timer->removeTimeout(NULL);
(gdb) exploitable -v
'exploitable' version 1.32
Linux ubuntu 5.3.0-51-generic #44-Ubuntu SMP Wed Apr 22 21:09:44 UTC 2020 x86_64
Signal si_signo: 11 Signal si_addr: 0
Nearby code:
   0x00000000005ba1be <+30>:    call   QWORD PTR [rdx+0x68]
   0x00000000005ba1c1 <+33>:    xor    eax,eax
   0x00000000005ba1c3 <+35>:    mov    esi,eax
   0x00000000005ba1c5 <+37>:    mov    rcx,QWORD PTR [rbp-0x10]
   0x00000000005ba1c9 <+41>:    mov    rdx,QWORD PTR [rcx+0x118]
=> 0x00000000005ba1d0 <+48>:    mov    rdi,QWORD PTR [rdx]
   0x00000000005ba1d3 <+51>:    mov    QWORD PTR [rbp-0x18],rdi
   0x00000000005ba1d7 <+55>:    mov    rdi,rdx
   0x00000000005ba1da <+58>:    mov    rdx,QWORD PTR [rbp-0x18]
   0x00000000005ba1de <+62>:    call   QWORD PTR [rdx+0x18]
Stack trace:
#  0 P2PDetector::performShutdown at 0x5ba1d0 in /home/qdl/fuzzing/vermont-debug/vermont
#  1 Module::shutdown at 0x618b88 in /home/qdl/fuzzing/vermont-debug/vermont
#  2 CfgHelper<P2PDetector, P2PDetectorCfg>::shutdown at 0x50bfc1 in /home/qdl/fuzzing/vermont-debug/vermont
#  3 ConfigManager::shutdown at 0x4e89c6 in /home/qdl/fuzzing/vermont-debug/vermont
#  4 main at 0x4e5d82 in /home/qdl/fuzzing/vermont-debug/vermont
Faulting frame: #  0 P2PDetector::performShutdown at 0x5ba1d0 in /home/qdl/fuzzing/vermont-debug/vermont
Description: Access violation near NULL on source operand
Short description: SourceAvNearNull (16/22)
Hash: efba8b71d7eb72f594af08922d936240.efba8b71d7eb72f594af08922d936240
Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation, which may mean the application crashed on a simple NULL dereference to
data structure that has no immediate effect on control of the processor.
Other tags: AccessViolation (21/22)

cwtriage doesn't play nicely when binaries implicitly read from stdin

I generally set my binaries up to read from stdin by default. This works fine with afl, however:

$ cwtriage -afl -root xxx-output/
2015/08/11 11:23:32 internal error: Job command too short: {xxx-output/xxx-slave-1/crashes/id:000000 0xc20801a960 [./xxx-fuzz]}

Even if you work around this with somethng like:

$ cwtriage -match crashes.\*id -root xxx-output/ -- ./xxx-fuzz \< @@

you get errors:

Command: ./xxx-fuzz < xxx-output/xxx-slave-5/crashes/id:000000
File: xxx-output/xxx-slave-1/crashes/id:000000
Error: no gdb output

I think you could do this with something like 'gdb -ex "set args < testcase"' or by modifying the gdb commands ('run' -> 'run < testcase'). I looked over it for a bit, and don't see any clean way to start gdb where it will Just Work. This means the interface between crashwalk.go and gdb.go would have to include if it's expecting the testcase via stdin?

-match doesnt exclude .cwtidy

This has a fun side effect! Every time you run it, it creates another .cwtidy directory in your cwtidy directory.

Example:

Command: xxx output/crashes/.cwtidy/.cwtidy/.cwtidy/yyy
File: output/crashes/.cwtidy/.cwtidy/.cwtidy/yyy
Error: no crash detected

Add output to file option

Hi,

It would be useful to have a way to save the analysis of the templates to a file. Right now since after the -- we need to pass the command to run I can't pipe the output to a file (> out.txt) since the app get's that > out.txt as part of the arguments of the target binary.

Good job with the tool. It's very useful!

Non-afl mode doesn't detect crashes

root@35efc6731a98:~/fuzz-results/flvdumper#  ~/golang/bin/cwtriage -t 300 -root . -match crashes.\*id -- flvdumper -a @@ 2>&1 | tail
Timeout: 300
Error: no crash detected
---------
2015/11/16 09:11:11 ------
Command: flvdumper -a o/crashes/id:000141,sig:11,src:000937,op:havoc,rep:8
File: o/crashes/id:000141,sig:11,src:000937,op:havoc,rep:8
Memory Limit: -1
Timeout: 300
Error: no crash detected
---------
root@35efc6731a98:~/fuzz-results/flvdumper# pwd
/root/fuzz-results/flvdumper
root@35efc6731a98:~/fuzz-results/flvdumper# find -type d
.
./o
./o/queue
./o/queue/.state
./o/queue/.state/auto_extras
./o/queue/.state/variable_behavior
./o/queue/.state/redundant_edges
./o/queue/.state/deterministic_done
./o/crashes
./o/hangs
./i

question

Hi.

I have a question.

I am using ASan.

Can I use Crashwalk?

How do you handle duplicate testcase issues?

Thanks.

runtime/cgo: out of memory in thread_start

Hi,
I am getting following error "runtime/cgo: out of memory in thread_start"
Appreciate if anyone could help me to resolve this error.

$cwtriage -root . -tidy -afl

---CRASH SUMMARY---
Filename: syncdir3/fuzzer1/crashes/id:000046,sig:11,src:001292,op:flip1,pos:34
SHA1: 236d39b68f31df96b3a18f137b64c7515c3add8a
Classification: PROBABLY_EXPLOITABLE
Hash: dd4b5faef6857d28b473ce80ddc9299d.e7ea0f15a8da5c1bcb82f89895d16c14
Command: ./BUILD/pngtest syncdir3/fuzzer1/crashes/id:000046,sig:11,src:001292,op:flip1,pos:34
Faulting Frame:
test_one_file @ 0x0000000000401df5: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest
Disassembly:
Stack Head (3 entries):
__sigsetjmp @ 0x00007ffff731c1b0: in (BL)
test_one_file @ 0x0000000000401df5: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest
main @ 0x0000000000403dd9: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest
Registers:
rax=0x0000000000000000 rbx=0x000000000044bdfd rcx=0x0000000000653b10 rdx=0x0000000000653b10
rsi=0x0000000000000000 rdi=0x0000000000000000 rbp=0x0000000000000002 rsp=0x00007fffffffd988
r8=0x00007fffffffd8d0 r9=0x0000000000000000 r10=0x000000000044c0a3 r11=0x0000000000000212
r12=0x0000000000000002 r13=0xfffffffffffffffc r14=0xfffffffffffffffc r15=0x00007fffffffe15e
rip=0x00007ffff731c1b0 efl=0x0000000000010246 cs=0x0000000000000033 ss=0x000000000000002b
ds=0x0000000000000000 es=0x0000000000000000 fs=0x0000000000000000 gs=0x0000000000000000
Extra Data:
Description: Access violation near NULL on destination operand
Short description: DestAvNearNull (15/22)
Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control write address and/or value. However, it there is a chance it could be a NULL dereference.
---END SUMMARY---
runtime/cgo: out of memory in thread_start
SIGABRT: abort
PC=0x7f5a766fb428 m=2

goroutine 0 [idle]:

goroutine 1 [runnable]:
syscall.Syscall(0x1, 0x1, 0xc82037b800, 0x748, 0x748, 0x748, 0x0)
/usr/lib/go-1.6/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.write(0x1, 0xc82037b800, 0x748, 0x800, 0x0, 0x0, 0x0)
/usr/lib/go-1.6/src/syscall/zsyscall_linux_amd64.go:1064 +0x5f
syscall.Write(0x1, 0xc82037b800, 0x748, 0x800, 0xc81ffd80ae, 0x0, 0x0)
/usr/lib/go-1.6/src/syscall/syscall_unix.go:180 +0x4d
os.(*File).write(0xc820088008, 0xc82037b800, 0x748, 0x800, 0x0, 0x0, 0x0)
/usr/lib/go-1.6/src/os/file_unix.go:249 +0xaa
os.(*File).Write(0xc820088008, 0xc82037b800, 0x748, 0x800, 0xc8200d0101, 0x0, 0x0)
/usr/lib/go-1.6/src/os/file.go:136 +0x8a
fmt.Fprintln(0x7f5a76ff6220, 0xc820088008, 0xc82004b9f8, 0x1, 0x1, 0x4106ae, 0x0, 0x0)
/usr/lib/go-1.6/src/fmt/print.go:255 +0xa5
fmt.Println(0xc82004b9f8, 0x1, 0x1, 0x5f33c0, 0x0, 0x0)
/usr/lib/go-1.6/src/fmt/print.go:264 +0x73
main.main()
/home/sd/go/src/github.com/bnagy/crashwalk/cmd/cwtriage/main_unix.go:204 +0x18ba

goroutine 17 [syscall, 1 minutes, locked to thread]:
runtime.goexit()
/usr/lib/go-1.6/src/runtime/asm_amd64.s:1998 +0x1

goroutine 3 [runnable]:
syscall.Syscall(0x0, 0x8, 0xc82026ea28, 0x8, 0x0, 0x8, 0x0)
/usr/lib/go-1.6/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.readlen(0x8, 0xc82026ea28, 0x8, 0x1b, 0x0, 0x0)
/usr/lib/go-1.6/src/syscall/zsyscall_linux_amd64.go:1085 +0x51
syscall.forkExec(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ebf8, 0x11cc1, 0x0, 0x0)
/usr/lib/go-1.6/src/syscall/exec_unix.go:202 +0x567
syscall.StartProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ebf8, 0x2, 0x4, 0x0, 0x0)
/usr/lib/go-1.6/src/syscall/exec_unix.go:240 +0x6b
os.startProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ee30, 0xc8200c6900, 0x0, 0x0)
/usr/lib/go-1.6/src/os/exec_posix.go:45 +0x33e
os.StartProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ee30, 0x0, 0x0, 0x0)
/usr/lib/go-1.6/src/os/doc.go:28 +0x69
os/exec.(*Cmd).Start(0xc8204eaa00, 0x0, 0x0)
/usr/lib/go-1.6/src/os/exec/exec.go:332 +0x761
github.com/bnagy/crashwalk/gdb.(*Engine).Run(0x7fd3e0, 0xc8204f7780, 0x2, 0x2, 0xc8204f12c0, 0x4d, 0x32, 0x3c, 0x0, 0x0, ...)
/home/sd/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:446 +0x1028
github.com/bnagy/crashwalk.process(0xc82006b1e0, 0xc82001c120, 0xc82001c060, 0xc82000e290)
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x161f
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x490

goroutine 4 [chan send]:
github.com/bnagy/crashwalk.(*Crashwalk).Run.func2.1(0xc8204f1950, 0x45, 0x7f5a76ff62e0, 0xc8204fd040, 0x0, 0x0, 0x0, 0x0)
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:572 +0x239
path/filepath.walk(0xc8204f1950, 0x45, 0x7f5a76ff62e0, 0xc8204fd040, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:349 +0x80
path/filepath.walk(0xc8202f89a0, 0x18, 0x7f5a76ff62e0, 0xc82031b040, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc
path/filepath.walk(0xc8203000d0, 0x10, 0x7f5a76ff62e0, 0xc82031ad00, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc
path/filepath.walk(0xc820300080, 0x8, 0x7f5a76ff62e0, 0xc82031ac30, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc
path/filepath.walk(0x7fff5e12a16a, 0x1, 0x7f5a76ff62e0, 0xc82006b790, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc
path/filepath.Walk(0x7fff5e12a16a, 0x1, 0xc8200105a0, 0x0, 0x0)
/usr/lib/go-1.6/src/path/filepath/path.go:396 +0xe1
github.com/bnagy/crashwalk.(*Crashwalk).Run.func2(0xc82006b1e0, 0xc82001c120)
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:586 +0x84
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:590 +0x4c9

goroutine 5 [semacquire, 1 minutes]:
sync.runtime_Semacquire(0xc82000e29c)
/usr/lib/go-1.6/src/runtime/sema.go:47 +0x26
sync.(*WaitGroup).Wait(0xc82000e290)
/usr/lib/go-1.6/src/sync/waitgroup.go:127 +0xb4
github.com/bnagy/crashwalk.(*Crashwalk).Run.func3(0xc82000e290, 0xc82009e1e0, 0xc82001c060, 0xc82006b1e0)
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:594 +0x21
created by github.com/bnagy/crashwalk.(*Crashwalk).Run
/home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:601 +0x50c

rax 0x0
rbx 0x7f5a766c4d68
rcx 0x7f5a766fb428
rdx 0x6
rdi 0x11853
rsi 0x11854
rbp 0x1
rsp 0x7f5a766c4b98
r8 0x2b
r9 0x7f5a76a8b540
r10 0x8
r11 0x206
r12 0x2c
r13 0x70458c
r14 0x0
r15 0x8
rip 0x7f5a766fb428
rflags 0x206
cs 0x33
fs 0x0
gs 0x0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.