projectdiscovery
Screnshot/Wappalyzer issue introduced in 1.6.0/1.6.1
httpx version: 1.6.0/1.6.1 (docker)
Current Behavior:
When adding the -ss/-screenshot argument, a go wappalyzer error is shown. By downgrading to 1.5.0 this issue is gone, indicating this is a newly introduced issue
Expected Behavior:
The program running without error
Steps To Reproduce:
docker run --rm projectdiscovery/httpx:v1.6.1 -u google.com -fr -screenshot- Error shown:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x129b632]
goroutine 101 [running]:
github.com/projectdiscovery/wappalyzergo.(*Wappalyze).checkHeaders(...)
/go/pkg/mod/github.com/projectdiscovery/[email protected]/fingerprint_headers.go:10
github.com/projectdiscovery/wappalyzergo.(*Wappalyze).Fingerprint(0x0, 0x40855ee3f7aa84c9?, {0xc0042a2000, 0x4a5fb, 0x4c000})
/go/pkg/mod/github.com/projectdiscovery/[email protected]/tech.go:57 +0x92
github.com/projectdiscovery/wappalyzergo.(*Wappalyze).FingerprintWithInfo(0x0, 0xc003df8000?, {0xc0042a2000?, 0x26c70?, 0x26c70?})
/go/pkg/mod/github.com/projectdiscovery/[email protected]/tech.go:172 +0x32
github.com/projectdiscovery/httpx/runner.(*Runner).analyze(_, _, {_, _}, {{0xc0026b4280, 0xa}, {0x0, 0x0}, {0x0, 0x0}}, ...)
/app/runner/runner.go:2007 +0x809a
github.com/projectdiscovery/httpx/runner.(*Runner).process.func1({{0xc0026b4280, 0xa}, {0x0, 0x0}, {0x0, 0x0}}, {0x15f9edf?, 0x3?}, {0x1627192, 0xa})
/app/runner/runner.go:1196 +0x12a
created by github.com/projectdiscovery/httpx/runner.(*Runner).process in goroutine 1
/app/runner/runner.go:1194 +0x87a
Running the older version:
docker run --rm projectdiscovery/httpx:v1.5.0 -u google.com -fr -screenshot- httpx exists without error
the issue does not pop up without the screenshot argument, indicating that it's related.
Anything else:
Weird behavior is that even when pulling the v1.6.1, it shows that the current version is 1.6.0 (and is outdated, see screenshot). The image pulled is cleary 1.6.1, this could be a forgotten version bump as i observe the same behavior when executing the binary without docker
By specifying the -td alongside -ss, it works as I thought.
Without -td:
With -td:
Came here after reviewing all the code changes from 1.6.0-1.6.1, saw the missing version bump and the expected -tech-detect(when doing screenshot) in 1699 I assume.
