fix for bug 8456 #2465
fix for bug 8456 #2465
Conversation
|
I don't see any issues with this change, but I haven't looked at any of the surrounding jtr code before |
|
Just tested this on an ARMLE machine with and without the cpuinfo dir present, trying to trigger with and no errors are bugging the user. |
|
Hmm, with the patch, using my contrived test, I'm still seeing So, doesn't seem to solve on a x64 Linux platform when the bins are missing, but does solve when the whole cpuinfo dir is missing. Hmm let's see if we can't fix that. |
|
As mentioned on IRC, the reason to be at least binary-specific is the case where someone's bonehead antivirus decides that that these binaries are evil and should be quarantined (and thus, leave the dir in tact). |
|
your way fixes my issue as well as possible others, looks good |
Fix up PR #2465
|
Tested a real jtr module run with the cpuinfo bins missing, and it correctly defaulted to a "run.linux.x86.any/john" binary, and with the cpuinfo bins in tact, the module used "run.linux.x64.mmx/john", also as expected. Landing this. |
[FixRM #8456] Thanks @zerochaos!
This could be way more DRY. At least there's a YARD-ish comment. This fixes up rapid7#2465 to be a more complete solution. [SeeRM rapid7#8465]
On systems without bundled johntheripper (either by removing the bundled version or by no compatible version shipped) the system john is used. In this case, all of the checking for compatible bundled jtr makes no sense and as such we can shortcut out of this to not only reduce the size of msf (for embedded) but also to speed execution (saving multiple calls to some random bundled binary cpuinfo*.bin).
This patch makes it very easy to simply remove cpuinfo and msf will not try to run it when missing and default to running john from the path.