build_id2: A maintained way to uniquely represent the build of the current binary
The build_id2 crate is a maintained and updated fork of build_id.
With it, you can obtain a Uuid uniquely representing the build of the current binary.
This is intended to be used to check that different processes are indeed invocations of identically laid out binaries.
As such:
- It is guaranteed to be identical within multiple invocations of the same binary.
- It is guaranteed to be different across binaries with different code or data segments or layout.
- Equality is unspecified if the binaries have identical code and data segments and layout but differ immaterially (e.g. if a timestamp is included in the binary at compile time).
Usage
Add the following to your Cargo.toml:
[]
= "0.16.1"
Then, you can use the get function to get the build id:
# let remote_build_id = get;
let local_build_id = get;
if local_build_id == remote_build_id else
The LibAFL Project
The LibAFL project is part of AFLplusplus and maintained by
- Andrea Fioraldi andrea@aflplus.plus
- Dominik Maier dominik@aflplus.plus
- s1341 github@shmarya.net
- Dongjia Zhang toka@aflplus.plus
- Addison Crump me@addisoncrump.info
Contributing
For bugs, feel free to open issues or contact us directly. Thank you for your support. <3
Even though we will gladly assist you in finishing up your PR, try to
- keep all the crates compiling with stable rust (hide the eventual non-stable code under
cfgs.) - run
cargo nightly fmton your code before pushing - check the output of
cargo clippy --allor./clippy.sh - run
cargo build --no-default-featuresto check forno_stdcompatibility (and possibly add#[cfg(feature = "std")]) to hide parts of your code.
Some parts in this list may sound hard, but don't be afraid to open a PR if you cannot fix them by yourself. We will gladly assist.