googleprojectzero
Installation is currently hit & miss on mac os
First, the proposed way to grab TinyInst doesn't work:
git clone --recurse-submodules [email protected]:googleprojectzero/TinyInst.git
Cloning into 'TinyInst'...
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Changing to just use the https for the TinyInst repo works.
Second, when you try to build:
(base) cmp3149:Jackalope adg326$ cd build
(base) cmp3149:build adg326$ cmake -G Xcode ..
-- The C compiler identification is AppleClang 12.0.0.12000032
-- The CXX compiler identification is AppleClang 12.0.0.12000032
CMake Error at TinyInst/third_party/CMakeLists.txt:18 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at TinyInst/third_party/CMakeLists.txt:18 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "/Users/adg326/Jackalope/build/CMakeFiles/CMakeOutput.log".
For the git error: Right, that only works if you have ssh key configured in github. I'll make a note of that in the readme.
First time I see the 2nd error though. Do you have Xcode installed and have you ran it at least once (it installs some tools only on the 1st run)?
Definitely have xcode installed/xcode-select ran long ago, etc.
Tried first on a "clean" setup but with git and command line dev, since I may point students at this in a class this spring, but then on my normal dev machine, which is compiling things all over the place. I'm very interested in getting this running, be really nice to have a mac-friendly fuzzer come with https://github.com/trailofbits/deepstate, especially one that makes custom mutators (so we could add awareness of test structure) easy!
Hi, Same problem here when compiling TinyInst. and "sudo xcode-select --reset" doesn't help.
Cool! Glad to hear that updating cmake resolves the issue.
@agroce Does this resolve the issue for you as well?
Fixed. And
./fuzzer -in in -out out -t 1000 -delivery shmem -instrument_module test -target_module test -target_method __Z4fuzzPc -nargs 1 -iterations 10000 -persist -loop -cmp_coverage -- ./test -m @@
works. When I tried to use it on a DeepState executable, it didn't work, but I'm guessing this is just me not having grasped all the required arguments' meanings, etc.:
~/Jackalope/build/Release/fuzzer -in corpus -out fuzz -t 1000 -delivery file -instrument_module Runlen -target_module Runlen -target_method __Z4fuzzPc -nargs 1 -iterations 10000 -persist -loop -cmp_coverage -- ./Runlen --input_which_test Runlength_EncodeDecode --input_test_file @@
Fuzzer version 0.01
1 input files read
Running input sample corpus/ffd9de9abb7f26f888c09183b2da0e2b4292f17d.pass
[-] PROGRAM ABORT : Error ((os/kern) failure) calling task_for_pid
Location : MachTarget(), /Users/adg326/Jackalope/TinyInst/macOs/machtarget.cpp:34
ah, right, task_for_pid, that means the fuzzer doesn't have the rights to attach to the target process. This can be resolved in one of two ways:
-
Running the fuzzer with sudo (possibly SIP needs to be disabled as well, but not sure for non-system targets).
-
Depends on how the target is compiled. I noticed that if the target is compiled on the comand line (e.g. with clang, gcc, etc.) it results in this error. However, if the target is compiled from xcode, it just works with normal user permissions. Not sure exactly what xcode does differently.
Likely related to the 2nd point about Xcode:
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_debugger
Xcode automatically adds the Get Task Allow entitlement to apps that you build for debugging, while removing the entitlement before App Store submission. This enables Xcode itself to attach to and debug your app during development.
Aha! Permissions. Hmm. sudo should fix it, though for a more ambitious target not entirely thrilled to fuzz under sudo. :)
sudo worked, but it hit another snag...
sudo ~/Jackalope/build/Release/fuzzer -in corpus -out fuzz -t 1000 -delivery file -instrument_module Runlen -nargs 1 -iterations 10000 -cmp_coverage -- ./Runlen --input_which_test Runlength_EncodeDecode --input_test_file @@
Fuzzer version 0.01
1 input files read
Running input sample corpus/ffd9de9abb7f26f888c09183b2da0e2b4292f17d.pass
Instrumented module Runlen, code size: 49152
TRACE: Initialized test input buffer with data from `fuzz/input_1`
TRACE: Running: Runlength_EncodeDecode from /Users/adg326/deepstate/examples/Runlen.cpp(55)
[-] PROGRAM ABORT : Debugger object could not be found in the map, task port = (3375)
Location : catch_mach_exception_raise_state_identity(), /Users/adg326/Jackalope/TinyInst/macOS/debugger.cpp:1311
has it mostly been tried on xcode-compiled targets, rather than command line clang-built stuff?
Hmm, that's a strange error to get, my test app works normally with sudo, but I can reproduce with your target. Not sure if sudo is to blame here or something else. Will investigate.
So, it's not about sudo or build, I verified that the same error still occurs for Runlen even if it's built with Xcode and ran without sudo.
The error in question is raised because the debugger is getting an exception from an unexpected task port and thus doesn't know how to handle it.
It would be helpful if you could point out any potentially related behaviour in your target such as:
- Does the target create child processes
- Does the target itself act as a debugger
- Does the target do something related to exception ports
- Any other behavior you can think of that might be related.
Right, fork() seems to be the problem here. If you add --fork=false to the Runlen command line arguments, it seems to work.