hachoir VS noseyparker

https://github.com/vstinner/hachoir/blob/main/hachoir/subfil...

File signature:

I contributed a number of file formats a few years ago (and attempted numerous others) but ran into a number of problems with certain file formats:

1. It's not possible to read from the file until a multiple byte termination sequence is detected. [1]

2. You can't read sections of a file where the termination condition is the presence of a sequence of bytes denoting the next unrelated section of the file (and you don't want to consume/read these bytes) [2]

3. The WebIDE at the time couldn't handle very large file format specifications such as Photoshop (PSD) [3]

4. Files containing compressed or encrypted sections require a compression/encryption algorithm to be hardcoded into Kaitai struct libraries for each programming language it can output to.

The WebIDE I particularly liked as it makes it easy to get started and share results. I also liked how Kaitai Struct allows easy definition of constraints (simple ones at least) into the file format specification so that you can say "this section of the file shall have a size not exceeding header.length * 2 bytes".

Some alternative binary file format specification attempts for those interested in seeing alternatives, each with their own set of problems/pros/cons:

1. 010 Editor [4]

2. Synalysis [5]

3. hachoir [6]

4. DFDL [7]

[1] https://github.com/kaitai-io/kaitai_struct/issues/158

[2] https://github.com/kaitai-io/kaitai_struct/issues/156

[3] https://raw.githubusercontent.com/davidhicks/kaitai_struct_f...

[4] https://www.sweetscape.com/010editor/repository/templates/

[5] https://github.com/synalysis/Grammars

[6] https://github.com/vstinner/hachoir/tree/main/hachoir/parser

[7] https://github.com/DFDLSchemas/

Another one sort of related is hachoir, and specifically the hachoir-metadata script: https://github.com/vstinner/hachoir

Yes!

Sometimes a file has no extension. Other times the extension is a lie. Still other times, you may be dealing with an unnamed bytestring and wish to know what kind of content it is.

This last case happens quite a lot in Nosey Parker [1], a detector of secrets in textual data. There, it is possible to come across unnamed files in Git history, and it would be useful to the user to still indicate what type of file it seems to be.

I added file type detection based on libmagic to Nosey Parker a while back, but it's not compiled in by default because libmagic is slow and complicates the build process. Also, libmagic is implemented as a large C library whose primary job is parsing, which makes the security side of me jittery.

I will likely add enabled-by-default filetype detection to Nosey Parker using Magika's ONNX model.

[1] https://github.com/praetorian-inc/noseyparker

Yes and no.

On the one hand, Nosey Parker is effectively a special-purpose `grep` with a bunch of security-relevant patterns built-in, including one for PEM-encoded keys: <https://github.com/praetorian-inc/noseyparker/blob/main/data...>

On the other hand, to naively run the check you describe, you would need access to a copy of all of GitHub, which isn't feasible.

What you can do with Nosey Parker is use its GitHub enumeration features to specify your GitHub organization and a list of GitHub usernames you are interested in, and scan against just those. This will implicitly list all the relevant public repositories, clone them, and scan their entire history.

For your use case, another thing you could do is use the new GitHub code search (<https://cs.github.com>) to regex search for particular keys or tokens. That new search seems to cover lots of the public content available on GitHub.

Also, to put some color on this use case: in offensive security engagements (aka "red team" engagements) at Praetorian, we frequently find leaked credentials or tokens on GitHub or elsewhere, which allow us deeper access into the client's systems. It's a significant problem.

A tool just got open-sourced called Nosey Parker that scans commits and git history for secrets. You could look at Nosey Parker's source code to see how they scan commits and design your tool based on that.