backhand

backhand copied to clipboard

This is mostly a copy from backhand-cli's unsquashfs, but with all the args/progress handling removed and more thorough error handling.

Due to the dependency on rayon, the utility is currently gated behind the util feature of backhand.

I tried also gating the nix dependency on the feature, but it was hard due to it showing up in BackhandError.

Fixes: #354

I made some suggestions with https://github.com/lovesegfault/backhand/pull/1.

Merged into the branch, thanks a bunch @rbran :)

I think the remaining issue is MSRV.

Merged into the branch, thanks a bunch @rbran :)

I think the remaining issue is MSRV.

I wonder if limiting the MSVR policy to only default-features is fine? I'd have to see what the default behavior is for other libraries that do this.

Merged into the branch, thanks a bunch @rbran :)

I think the remaining issue is MSRV.

To avoid the problem, can you use nix::unistd::fchownat and nix::unistd::FchownatFlags::NoFollowSymlink instead of std::os::unix::fs::lchown?

Alternately, add a #[cfg(feature = "unix_chown")] to the function.

I made some suggestions with https://github.com/rbran/backhand/commit/2ed4a52649fa7a914de16436c9706d0b8c632a8d

This Christmas I was thinking about this API 😂

Maybe it's better to not access the filesystem directly using std::fs or nix. Instead having a trait that implements all the filesystem functionality, and pass it's implementation as parameter.

That trait will be implemented using std by default, but also allowing the user to implement his way to create a manipulate files. This is especially useful in no_std environments.

Bonus this will also allow some cool fuzzing targets.

I could not find a crate that does that.

This goes beyond this PR, but well.. that's something that I think is pretty usefull.

This Christmas I was thinking about this API 😂

Maybe it's better to not access the filesystem directly using std::fs or nix. Instead having a trait that implements all the filesystem functionality, and pass it's implementation as parameter.

That trait will be implemented using std by default, but also allowing the user to implement his way to create a manipulate files. This is especially useful in no_std environments.

Bonus this will also allow some cool fuzzing targets.

I could not find a crate that does that.

This goes beyond this PR, but well.. that's something that I think is pretty usefull.

I haven't put much thought into this, but yes having a way of creating a "fake" filesystem would be useful for fuzzing

This Christmas I was thinking about this API 😂 Maybe it's better to not access the filesystem directly using std::fs or nix. Instead having a trait that implements all the filesystem functionality, and pass it's implementation as parameter. That trait will be implemented using std by default, but also allowing the user to implement his way to create a manipulate files. This is especially useful in no_std environments. Bonus this will also allow some cool fuzzing targets. I could not find a crate that does that. This goes beyond this PR, but well.. that's something that I think is pretty usefull.

I haven't put much thought into this, but yes having a way of creating a "fake" filesystem would be useful for fuzzing

https://github.com/queer/floppy-disk

https://github.com/queer/floppy-disk

That's almost it, but I was also thinking in something a little bit simpler, maybe something like this:

pub trait FsImpl {
 type File;
 fn read(file: &mut Self::File, buf: &mut [u8]) -> Result<()>;
 fn write(file: &mut Self::File, buf: &[u8]) -> Result<()>;
 //....
}

struct StdFS;
impl FsImpl for StdFS {
 type File = std::fs::File;
  fn read(file: &mut Self::File, buf: &mut [u8]) -> Result<()> { file.read(buf) }
 //....
}

impl Squashfs<FS: FsImpl = StdFS> {
 fn write(&mut self, output: &mut FS::File) { ... }
}

If I got more time to work on that I'll try to implement it. Maybe I'll have that added to https://github.com/wcampbell0x2a/backhand/pull/366 once I start experimenting with https://github.com/AFLplusplus/LibAFL/

@rbran I tried the instructions at https://github.com/AFLplusplus/LibAFL/tree/main/libafl_libfuzzer at some point. But I had issues and didn't have time to file an issue.

@rbran I tried the instructions at https://github.com/AFLplusplus/LibAFL/tree/main/libafl_libfuzzer at some point. But I had issues and didn't have time to file an issue.

I'm currently using libafl_qemu for other projects, I also had issues with the implementation and had to solve then by submitting PRs/Issues to LibAFL. If you want to spend more time trying, use a example implementation, like: https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/libfuzzer_libpng