Some Fritz!Box devices also run in Big Endianess mode. However, since
"uname -a" always returns "mips" and the "file"-command is not
available, autodetection is not an easy task.
The check()-function now checks, whether the device is really
vulnerable.
Furthemore, it's possible to send 92 bytes.
None of the lorcon / lorcon2 modules have been functional for a long
time, due to the lack of a "Lorcon" gem. It's unclear where it went.
I'm happy to include it and get these working again, but until someone
comes up with some functional code (hint: 'gem install' doesn't work) I
don't see any reason to keep shipping these.
Is there some trick people are doing to make these work? As far as I can
see, they are broken by default.
````
msf auxiliary(wifun) > show options
Module options (auxiliary/dos/wifi/wifun):
Name Current Setting Required Description
---- --------------- -------- -----------
CHANNEL 11 yes The initial channel
DRIVER autodetect yes The name of the wireless driver
for lorcon
INTERFACE wlan0 yes The name of the wireless
interface
msf auxiliary(wifun) > run
[*] The Lorcon2 module is not available: cannot load such file --
Lorcon2
[-] Auxiliary failed: RuntimeError Lorcon2 not available
[-] Call stack:
[-]
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/exploit/lorcon2.rb:67:in
`open_wifi'
[-]
/home/todb/git/rapid7/metasploit-framework/modules/auxiliary/dos/wifi/wifun.rb:29:in
`run'
[*] Auxiliary module execution completed
````
This correct msftidy's disclosure date check to do the following:
1. If the module has a disclosure date, the check should kick in.
2. If the module is an exploit, and doesn't have a disclosure
date, then it will be flagged.
3. If the module is an auxiliary, and doesn't have a disclosure
date, then it will NOT be flgged (because not all aux modules
target bugs/vulns like exploits do).
I've seen a couple PRs targeting the wrong branch. Many projects have a
workflow where PRs should hit `develop` or `release` or something, but
Metasploit-Framework wants PRs targeted against `master`.
Also, warn against fixing too much in one PR since those kinds of PRs
are a) harder to validate and b) might be all wrong anyway. We don't
want people committing a bunch of work when the fundamental approach
isn't going to fly.