Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FILEFORMAT incorrectly states one entry per line #384

Open
paulhargreaves opened this issue May 8, 2018 · 5 comments
Open

FILEFORMAT incorrectly states one entry per line #384

paulhargreaves opened this issue May 8, 2018 · 5 comments

Comments

@paulhargreaves
Copy link

paulhargreaves commented May 8, 2018

If any filenames have a newline then the output is multiple line, but the FILEFORMAT states 'Each line should contain a series of comma separated values corresponding to the columns listed in the file header.'

To reproduce: (Linux)

$ f="$(echo -e "foo\nbar")"; echo "HELLO" >> "$f"
$ hashdeep foo*
%%%% HASHDEEP-1.0
%%%% size,md5,sha256,filename
## Invoked from: /tmp/hashexam
## $ hashdeep foo
bar
## 
6,0084467710d2fc9d8a306e14efbe6d0f,3b09aeb6f5f5336beb205d7f720371bc927cd46c21922e334d47ba264acb5ba4,/tmp/hashexam/foo
bar
$
@ethus3h
Copy link

ethus3h commented May 12, 2018

I just encountered this when my scripts caught a failing audit.

For a test case, I ran: hashdeep -r SectionInfoCaches > 2018may11a12.csums
Here is the resulting file: https://gist.github.com/ethus3h/3291029ce0533c6af042a88d1f7be2f2

Then, I ran: hashdeep -rvvk 2018may11a12.csums -a SectionInfoCaches
with the result:

/nvme0n1p5/SectionInfoCaches/FRCCache{
    NoteCollectionPrimaryIdentifier = "BB1037FC-049E-40C7-9D15-2731C90F95B2";
    NoteCollectionSecondaryIdentifier = "imap:/e.wallace.fm@p30-imap.mail.me.com/Notes";
    NoteCollectionType = Store;
}/sectionInfo: Moved from /nvme0n1p5/SectionInfoCaches/FRCCache{
: Known file not used
: Known file not used
: Known file not used
: Known file not used
hashdeep: Audit failed
   Input files examined: 0
  Known files expecting: 0
          Files matched: 1
Files partially matched: 0
            Files moved: 1
        New files found: 0
  Known files not found: 4

Here is a tar file of the folder I tested on: https://github.com/ethus3h/personal/raw/825ffffa9f252a1067c3cff92e968965adaa2d11/2018may11a12n3.tar

@ethus3h
Copy link

ethus3h commented Sep 19, 2018

Aha, it turns out there is an undocumented -0 option to use null for the separator. This prevents this issue. I think all that is needed is adding it to the manpage.

@ethus3h
Copy link

ethus3h commented Sep 22, 2018

Well, as it turns out, auditing hashdeep files created using -0 isn't implemented. I guess that's why it's not documented...

@ethus3h
Copy link

ethus3h commented Sep 22, 2018

I think it would need to be implemented around

void state::md5deep_load_match_file(const char *fn)
.

@HaleTom
Copy link

HaleTom commented Sep 17, 2019

Related to the undocumented option:

Escape hashes and filenames with '\n' and '\\', support -z / --zero #389

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants