akaidiot / digestive Goto Github PK

Entropy as a single number is nice, a simple graph is nicer. Determining the width of the spark is an open issue here as well.

Preliminary tests seem to indicate that Entropy is slow in comparison with the hash digests...

Hoping that readinto() will be easy to do with libewf, this would be a great enhancement. The verification hash stored in the format could be verified somehow as well.

Using a fixed or configurable block size, a proper entropy plot could be created, writte to file and the name of the file returned as the digest result.

EWF images usually contain acquisition hashes used by ewfverify to check integrity of an image, digestive verify image.E01 (paging doctor #9) should be able to check this by reading the stored hashes in the image (and maybe just printing whatever wasn't calculated at acquisition time for good measure).

Currently using Travis. GH Actions are betterder.

main uses the supported format list from ewf, which raises ImportError when libewf is not installed. This should not break usage of non-ewf modules...

Something like a multi-document YAML file would be very suited for this. The --- separator is clear to humans and allows a program (maybe digestive --verify / --check) to stream the document.

So, something like the following:

file: tests/files/random.dd
md5: 257f5c2913ea856cb0a2313f167452d4
sha256: 810ec5f2086379f0e8000456dbf2aede8538fbc9d9898835f114c8771ed834b5

---
file: tests/files/random.E01
md5: 257f5c2913ea856cb0a2313f167452d4
sha256: 810ec5f2086379f0e8000456dbf2aede8538fbc9d9898835f114c8771ed834b5

Using the log as envisioned in #7 created with digestive digest --output digest.log --recursive /some/path, we should be able to call digestive verify digest.log to verify the digests of everything in digest.log.

A running progress bar, a percentage and an 'x or total bytes' should all be possible. Argument might make this easy using nargs='?'.

When digesting an E01 type image, memory usage of the python process increases over time. Not dramatically, it seems the buffering works fine, we're just leaking something (a pointer, return value?)

Most likely culprit is the ssize_t return value of libewf_handle_read_buffer, that's returned but never freed.