bincapz --ignore-self silently drops samples/

[tstromberg]

directory scans seem to be broken at HEAD:

% go run . -verbose samples/

Returns no results, but shows that it is at least trying:

time=2024-05-05T08:59:22.407-04:00 level=INFO source=/Users/t/src/bincapz_fix/bincapz.go:56 msg="bincapz starting"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=evasion/binary-opaque.yara warning="string \"$word_with_spaces\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=ref/email.yara warning="string \"$e_re\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=ref/ip.yara warning="string \"$ipv4\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=ref/ip_port.yara warning="string \"$ipv4\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=shell/background-sleep.yara warning="string \"$cmd_bg\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=systemd/no_docs_or_comments.yara warning="string \"$ex_comment\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=third_party/mthcht_thk_yara_rules.yar warning="string \"$string22_DynastyPersist_offensive_tool_keyword\" may slow down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=third_party/mthcht_thk_yara_rules.yar warning="rule is slowing down scanning"
time=2024-05-05T08:59:23.403-04:00 level=WARN source=/Users/t/src/bincapz_fix/pkg/rules/rules.go:70 msg=warning namespace=third_party/mthcht_thk_yara_rules.yar warning="string \"$string7_RDPassSpray_offensive_tool_keyword\" may slow down scanning"
time=2024-05-05T08:59:25.337-04:00 level=DEBUG source=/Users/t/src/bincapz_fix/pkg/action/scan.go:87 msg=scan config="{IgnoreSelf:true IgnoreTags:[] IncludeDataFiles:false MinFileScore:0 MinResultScore:1 OCI:false OmitEmpty:false Output:<nil> Renderer:{w:0x14000118048} Rules:0x14000174000 ScanPaths:[samples/] Stats:false}"
time=2024-05-05T08:59:25.337-04:00 level=INFO source=/Users/t/src/bincapz_fix/pkg/action/scan.go:100 msg="14531 rules loaded"
time=2024-05-05T08:59:25.337-04:00 level=INFO source=/Users/t/src/bincapz_fix/pkg/action/scan.go:23 msg="finding files in samples/ ..."

I also checked to see if it was a recursion issue, but it happens for any other directory, for example go run . samples/Linux/clean/. Looking at recent PRs, I think this could be a regression from #174. We'll also need a test case to make sure this doesn't happen again.

[tstromberg]

cc @egibs in case this rings a bell

[tstromberg]

This is so weird that maybe this is just my macOS machine.

Running bincapz against /bin works.

Running go run . samples/does-nothing/does-nothing doesn't work, but it does work if I copy the directory to /tmp. I thought maybe it was an issue with relative paths, but absolute paths within my repository don't seem to work either.

What a curious thing.. I wonder if anyone else is seeing this behavior.

[tstromberg]

Also, the weirdness does not seem dependent on directory scanning.

go run . samples/Linux/2024.sbcl.market/sbcl.dirty also shows no results.

[tstromberg]

Confirmed on my Linux box that go run . samples/ shows no results either.

I did figure it out though; if I set --ignore-self=false it works! I think the logic needs to be tightened up a bit.

[egibs]

cc @egibs in case this rings a bell

Yep, definitely a consequence of #167. I'll work on improving this 👍🏻

[tstromberg]

@egibs - I think if we change to just matching the YARA rule, and tightening the YARA rule up to include say, 2 of 3 unique strings from the bincapz binary, it should be sufficient. For example:

bincapz/pkg/rules.FS bincapz/pkg/report

[tstromberg]

After looking at the PR implementation, I think there was some confusion about #134 due to my vague wording: my intent was to only ignore the bincapz binary if encountered: for example, in a container image or in your $PATH. It was not to ignore content within the bincapz repository.

My apologies for the imprecise wording.