lifting-bits/grr

High-throughput fuzzer and emulator of DECREE binaries

grr's Issues

Port to using CMake

Port the project from using Makefiles to using CMake.

[QUESTION] Radamsa to C

What did you use to migrate Radamsa to C?
The code looks like you used something automatic. Is that correct?

Nice work!

Replace GRANARY_ASSERT with glog

GRR uses GRANARY_ASSERT, which is kind of a weird holdover from writing DBTs that can't depend on system libraries, and it's also very C-like. Now that we've made GRR start using cxx-common, we could easily upgrade it to use Google Log's CHECK macro.

Does this project use protobuf?

It doesn't look like there's any protobuf code anywhere, but there's two instances where it's referenced in the Makefile:

https://github.com/trailofbits/grr/blob/master/Makefile#L65

https://github.com/trailofbits/grr/blob/master/Makefile#L108

Removing those doesn't seem to cause any problems at compile or runtime.

Port to macOS

Basic block deduplication in the code cache

When the page hash is invalidated (e.g. because of a JIT), then all further executed code after a re-hash is triggered will be translated without consideration for whether or not code pages unrelated to the modified pages are different. Deduplication should only happen on the block level and not the trace level, and it should not be applied to blocks ending in conditional branches.

Add in the PID into the PathEntry data structure

Code coverage used to be computed differently and stored into a bitset. Since moving over to the path entry recording approach, the PID has stopped being included. Adding it back in would be useful.