The exploit works with the URLs fixed, installs the APK, but hangs at the Installing...
screen and never actually launches. We tried opening the APK in a setTimeout() intent
URI, but the previously launched intent seemed unresponsive. Andre had the bright
idea of re-opening the previously launched intent with invalid args, crashing it and
allow us to launch the payload.
See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in
I needed this to run a custom JS check for the Android
webview vuln when the exploit is served straight
through BES. The check already existed when using BAP,
so I tried to preserve that syntax, and also added a
:vuln_test_error as an optional error message.
This commit also does some mild refactoring of un-
useful behavior in BES.
* I verified that changes to PDF mixin do not affect any older modules that
generate PDF. I did this by (on each branch) running in irb, then
running the module and diffing the pdf's generated by each branch. There were
no changes.
* This refactors the logic of webview_addjavascriptinterface into a mixin (android.rb).
* Additionally, some behavior in pdf.rb had to be modified (in backwards-compatible ways).
Conflicts:
lib/msf/core/exploit/mixins.rb
Android 4.0, it turns out, has a different echo builtin than the other androids.
Until we can figure out how to drop a payload on a 4.0 shell, we cannot support it.
Arch detection allows mips/x86/arm ndkstagers to work, unfortunately
x86 ndkstager was not working, so it is disabled for now.
This commit changes how os_name and os_flavor are handled
for client-side exploits, matching recent changes to the
server-side exploits and scanner fingerprints.
This commit also updates the client-side fingerprinting to
take into account Windows 8.1 and IE 9, 10, and 11.