Android Overhaul #19154
Comments
|
|
i was also so frustrated in the 2018 that the metasploit stopped working for android , and now in 2024 when i thought i would give it a another try i found out no difference , it was the same! same issues, but seeing your posts increases our hope. Thanks |
|
Nothing works on my newer devices, This really needs to be fixed. |
|
The reason the Android Payloads built by the metasploit framework's msfvenom don't work is because they are only configured for Android 2.3.3 (SDK 10) upto Android 5.1 (SDK 22). Android 6.0 (SDK 23) and above introduced numerous changes to the way things are handled in Android such as Permissions, Services, etc etc. Here's a brief rundown of the changes made to Permissions and Service handling after SDK 22: Changes after Android 5.1 (SDK 22)Android 6.0 (Marshmallow, API 23)
Android 7.0 (Nougat, API 24)
Android 8.0 (Oreo, API 26)
Android 9.0 (Pie, API 28)
Android 10 (Q, API 29)
Android 11 (R, API 30)
Android 12 (S, API 31)
Android 13 (T, API 33)
Android 14 (API 34)
These changes reflect Android's ongoing efforts to enhance user privacy, security, and battery performance. Each major release has introduced stricter controls and optimizations, encouraging developers to adopt best practices for permission handling and service management. |
|
Aside from fixing the compatibility,we can also consider add polymorphism to the payload. By now,the payload have many part flagged by AV , like com.metasploit.satge or some words contain "metasploit". |
|
There are any plans to release an update for the "android payload"? It needs a lot of code-level upgrade to work on recent APIs |
|
As far as my understanding goes, there are no plans currently to update the payload. It will need to be a community effort, and no one has volunteered their services at this point. |
|
We can link it against SDK +26 to make it work with A14 and maintain some compatibility with A8 at least. Losing support for A6 is not a problem, no one uses it anymore. The framework already dropped support for older Windows versions as well |
I have 15 years of experience in Android applications. I've created numerous trojans and backdoors for mobile, and I can help. |
Let me guess we have to contact you privately through Telegram, Wikr or Email if we want your help? |
|
😂 No, just no! Bro this is GitHub and this is an open source repository, if you want to help like how you claim you can then Fork the repository and the Metasploit-Payloads repository as well, and start making and sharing your updates via Pull Requests! Help on Open Source projects doesn't come from Private Telescam.... I mean Telegram interactions, it comes from hard work, collaboration and community efforts most of the time. |
|
ITNOA Can you say some guide for starting this issue? thanks |
|
which issue were you wanting to tackle, I've outlined quite a bit |
|
Being unfamiliar with Android development, and Java, I'm not a good helper on this. However the payload is located here: https://github.com/rapid7/metasploit-payloads/tree/master/java/androidpayload and I would agree that getting the combability updated would be a best first step. If possible I'd avoid doing any design level changes, but its likely you'll need to in order to get the payload working correctly. I'd try to work on this in steps to avoid it become a huge snowball where every line of code has to be updated, but that may end up being the case anyways. If you need help, I'd suggest joining the discord channel. I think you'll get quicker responses there for code level questions. |
I was just kidding around 😂 😂 😂 . I’ve now forked the repository and made the necessary updates as suggested. I’ve also pushed the changes to my fork and created a pull request for review. Thanks for the guidance on contributing to open source projects. I appreciate the opportunity to help improve this project, and I'm looking forward to collaborating with the community! (edited by h00die) rapid7/metasploit-payloads#734 |
|
@h00die Do you agree to Migrate android build system to gradle from maven? android-maven-plugin does not update from 2019, and I think it is obsolete. if you agree with me, I think I can try to migrate this https://docs.gradle.org/current/userguide/migrating_from_maven.html |
|
I have no opinions or authority for android stuff, just highlighting the issues |
@h00die Who can I coordinate with for project changes? I actually want to know who is responsible/accountable for the Android part of the project? |
|
Likely someone at rapid7. They all have access to this issue and see these posts. However, it may not reach their threshold for addressing at the moment. You could try joining slack as well |
|
@bwatters-r7 do you have any idea? |
|
Hi there; uh, OK.... I'll try and answer some questions. I am no Android/Java Dev, but I occasionally poke at the code as needed. First, and I want to be as gentle as possible, but also blunt- Android is simply not one of our priorities; when we get research and feature cycles, our attention tends to go to things like supporting ADCS attacks, adding modules from the KEV list, or expanding the Linux Meterpreter architectures as we see increasing IoT running on lots of embedded platforms. That said, we will do our best to support anyone who takes this on as a project- No one here is going to complain if our android Meterpreter gets improved, but I think we need to determine a path before we start walking it, hence this issue by @h00die. We really do not have a resident in-house expert on Android, so even getting a strategic view can be difficult. To @soroshsabz's question about who is responsible/accountable for Android payloads: no one is, but then again, I would say no one is completely responsible/accountable for any one thing in Metasploit. Again, we will try. @h00die is right- please be patient. As you're asking for improvements, remember that we have 7 Android post modules, and if I recall correctly, several require the device to be rooted. Compare that to nearly 300 Windows post modules and 50 Linux post modules. When making requests and suggestions keep in mind that Android is simply not something that we see used nearly as much as Windows, Python, Java, or Linux Meterpreters, and we have no shortage of improvements we'd like to make to them, too 😓. Suggestions that are going to cause an explosion of code maintenance or testing surface for something we don't see used often are going to take longer to get landed/improved. Additions that streamline testing, building, and verification will make you lots of friends, though! First- Compatibility; we are not keeping up with modern Android- no one's going to argue this point. Several times we've looked at the path forward here, and we never came away with something solid. As stated, we don't have a "supported" android list, or a clear roadmap for what we should support. @soroshsabz is absolutely right to ask the question "what is the goal for compatibility" before we start thinking about a solution. This is a great place for community to start- what versions of Android do people see out in the wild? How are red teams using Android targets? What are people using Android implants for? In my experience, Android for Red Teams has been a bit of a gray area- corporations don't really issue a lot of phones, and there are a lot of ethical considerations for attacking BYOD infrastructure as part of a red team exercise, so most seem to keep their distance. That means a lot of requests we get surrounding Android are less corporate red teaming and more about hacking an ex's facebook app, and while we want to support independent hackers and red teamers, people wanting to hack ex's phones can go do anatomically impossible things with themselves as far as we are concerned. Laying out some definitive, professional workflows for red teaming Android would be really interesting and enlightening for us, and give us a much clearer understanding of the use case. Supporting multiple payload bands is a really cool idea we have talked about, but that would explode testing. Second, I'm going to caution about making huge changes off the bat- I'll chat with people about Maven, but we use Maven for our Java builds as well. I'll comment directly on some of the PRs, but remember that every change to the build needs to be checked, approved, and then we need to make changes to our docker image for building. Any changes to any Meterpreter also need to be determined if they are breaking changes or not- landing a change that causes a payload that worked yesterday to stop working today on the same hardware needs to have some documentation and a major release associated with it- calling that out in PRs would be very helpful, but it also means those changes need to wait for a larger release so we can make sure everyone knows that things might break. Prior to starting to make changes, it might be worthwhile to plan and provide a way to make testing easier, so we can have confidence changes will only affect the desired results (see earlier comment about not wanting to buy a dozen new phones every year). Third, when you're updating builds or really anything, do not forget to update documentation. I see some changes in PRs listed here that change how we build things, but nothing is reflected in documentation changes. We've got to be very clear what is happening, what we're supporting, and how/what that changes. Lastly, know that we really, really appreciate your involvement here, even if the pace sometimes appears glacial. These are conversations we've had internally, but no consensus has been reached, so community guidance is really appreciated. |
|
I believe Metasploit payloads for Android will still run on systems as recent as Android 10 (API 29). These payloads should successfully establish a session, but with diminished capabilities. With the intention of supporting both old and new versions of Android, one comparatively quick win would be augmenting the payload generation such that the SDK version is user-controlled, as discussed here: This will help support newer versions of Android without breaking the existing build infrastructure, although comes with an increased maintenance burden as this may require bumping the version every time there is a new SDK release (yearly). Reasonable defaults for the specified SDK version are up for debate. This would also save a lot of confusion. If the operator specifies an unsupported SDK version (ie, new SDK), the payload generation will fail with an error - as opposed to the current workflow, which is to deliver the APK to the target device before discovering that it will not run. |
I still see old and unsupported versions of Android occasionally. Usually old embedded systems.
I suggest file system access and network access as a minimum requirement for supported capabilities.
Excluding Android cell phones and BYOD Android devices (which are usually also cell phones), I commonly see:
I expect everyone has a similar experience. I also commonly see many embedded devices that are likely to be running Android, such as:
Less often, I see Android based devices for role-specific functions; ie, hand-held devices, such as barcode scanners. We may already have a bunch of Android exploit modules targeting embedded Android devices. Although a search for "android" in |
|
@bwatters-r7 chill down bro, it's for the sake of completing a challenge so it's def worth working on the android payload |
|
@h00die what there is so funny to laugh at? However, making a simple research I found that the key API to update may be those related to dynamic Dex in-memory loading method. If I'm not wrong the old payload is using Feedbacks? |
I wanted to start documenting some issues/enhancements for Android, as per slack convo.
The android payload was amazing, but @timwr (and whoever else has been working on it) hasn't had time to keep it up to date. I haven't played around with it for a while either, but am using it now for a presentation to children.
Ideas
Compatibility
the payload seems to be losing newer compatibility while trying to maintain older compatibility. I have a ZTE android 6.0.1 I use for demos, and all the payload stuff works great on there. a Samsung galaxy a03s on android 13 installs and some things work, but many give unexpected permissions errors (I believe part of #16208 is related). Maybe let a user pick which SDK version(s) they want to use. It could even be simple like 'pre android 6' and 'post android 6' kind of thing. I think the new android permission model is actually better for what we want anyways since it wont list an entire screen of permissions, but pop them up as we call things that need them. Likely a better scenario.
Related Issues
Persistence
Add persistence (on rooted at least)?
Related Issues
Bugs
New Modules
Related Issues
Enhancements
Etc
Just throwing this out there as it seems like a neglected, but still often used feature of metasploit. happy to hear some thoughts, but I don't know java, and haven't messed around with android phone hacking much.
The text was updated successfully, but these errors were encountered: