-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Msf::Payload::Apk: find_hook_point: Return full packagename.classname #16358
Conversation
Is the class not guaranteed to be |
What? See: #16358 (comment) Edit: Oh right, the package name. Yeah that should work. |
c36912d
to
69eb8ae
Compare
1b38291
to
b578ff7
Compare
I wouldn't call it a guarantee when dealing with random untrusted APK files, but yes, I've updated Also we blindly trust the application name and package name, so it is likely that this allows directory traversal, mitigated in part by appending
It turns out that the recursive search approach resolved multiple issues. Application names can be in the form of Activity names can be in the form of I've updated the PR to normalize application names and activity names instead of using the recursive approach. |
b578ff7
to
d9bd985
Compare
Before
After
|
Release notesThis change fixes a bug in the msfvenom APK injection code, where in some situations a suitable hook point could not be found. |
Thanks @bcoles! |
Ensure the
find_hook_point
method always returns the full class name including the package name.Most APK files define an application name including the full package name in
AndroidManifest.xml
, like this:When using a template APK file with msfvenom, the
backdoor_apk
method uses the full application name (including package name) when locating the smali class file (after converting.
to/
) like so:However, some APK files define an application name using only the class name without the full package name. For example:
backdoor_apk
the attempts to locate the smali class file like so:Dir.glob
is used to find the class file in./smali*/
directories within the decompiled APK directory; however, the search is not performed recursively, which prevents locating the smali file when short package names are used, as the class file is several directories deep.This PR resolves this issue by ensuring that
find_hook_point
returns the full package name and class name.It also checks
!File.symlink?
to prevent following symlinks - an oversight in the original code.It also ensures
find_hook_point
returnsnil
in the event that no hook points are found. Previously it would incorrectly and unintentionally return a Nokogiri::XML object which lead to confusing XML error messages while trying to locate the smali class file - an oversight in the original code.Fixes #13533. The issue originally described an issue when using the Netflix apk as a template. This PR fixes this issue, but another issue prevents rebuilding the Netflix apk.
Instead, this PR was tested using OpenVPN Connect – Fast & Safe SSL VPN Client 1.1.16 (arm64-v8a + arm + arm-v7a) (nodpi) (Android 4.0+).apk from apkmirror. Use at own risk.
Before
After