zinja-coder/apktool-mcp-server
apktool-mcp-server is hosted online, so all tools can be tested directly either in theInspector tabor in theOnline Client.
If you are the rightful owner of apktool-mcp-server and would like to certify it and/or have it hosted online, please leave a comment on the right or send an email to henry@mcphub.com.
apktool-mcp-server is a fully automated MCP server built on top of apktool to analyze Android APKs using LLMs like Claude, providing live reverse engineering support.
Try apktool-mcp-server with chat:
Has a README
Github repo has a README.md.
Has a License
Github repo has license info.
Server can be inspected
View server inspector
Server schema can be extracted
Can get at lease one tool info from the README or server.
Online hosted on MCPHub
Can be automatically deployed by MCPHub.
Has social accounts
Do not have any social accounts.
Claimed by the author or certified by MCPHub
If you are the author, claim authorship
AI Evaluation ReportTotal Score: 8/10
The agent demonstrates a strong ability to decode APK files, search for specific strings, and handle APKTool-related tasks. It effectively identifies issues with APK structure, such as missing smali directories or potential misidentification of APK files as Android App Bundles (AABs). The agent provides clear explanations and actionable next steps when encountering obstacles, such as incomplete extractions or unexpected file structures. However, it struggles with tasks requiring direct modification of smali code and rebuilding APKs, as seen in the root detection bypass task. Overall, the agent shows competence in analysis and problem-solving but needs improvement in executing complex modifications.
Test case 1
Score: 9/10read all APKTool-related files and directories in the current system (e.g., paths containing keywords like "apktool", "decoded", "apk"), return the complete list of files/directories and their path information, and confirm whether there is an already decoded APK project directory (e.g., "test-app-decoded") to provide a project path basis for subsequent tests.To accomplish this task, I will search for files and directories in the current system that contain keywords like "apktool", "decoded", and "apk". This will help identify any existing APKTool-related projects, including any already decoded APK project directories such as "test-app-decoded".
Let's proceed with the search to gather the necessary information. It seems that the search for files and directories containing keywords like "apktool", "decoded", and "apk" did not return any results. This indicates that there are no APKTool-related files or directories in the current system that match the specified criteria.
Summary:
- No files or directories found: There are no APKTool-related files or directories, including any decoded APK project directories such as "test-app-decoded".
If you have any specific paths you would like to check or if you need further assistance, please let me know!
Test case 2
Score: 9/10What is the package name and what are all the permissions requested by the application located at `/app/signed-release.apk`The application located at
/app/signed-release.apkhas been decoded successfully. Here are the details:Package Name and Permissions
-
Package Name:
- The package name is not explicitly mentioned in the decoded information, but it can typically be found in the
AndroidManifest.xmlfile.
- The package name is not explicitly mentioned in the decoded information, but it can typically be found in the
-
Permissions Requested:
- The permissions requested by the application are not directly listed in the provided output. However, they would typically be included in the
AndroidManifest.xmlfile.
- The permissions requested by the application are not directly listed in the provided output. However, they would typically be included in the
Next Steps
To retrieve the exact package name and the list of permissions requested by the application, I will extract and analyze the content of the
AndroidManifest.xmlfile. Let me proceed with that. The extraction of theAndroidManifest.xmlfile did not yield the expected package name or permissions, as the manifest content returned seems to be incomplete or malformed.Summary of Findings:
- Package Name: Not directly available from the manifest extraction.
- Permissions: Not listed in the manifest content retrieved.
Next Steps
To assist further, I can attempt to search for typical permission tags in the
AndroidManifest.xmlfile or check the structure more closely. Let me try to access the raw file content directly to see if more information can be retrieved. It seems that theAndroidManifest.xmlfile could not be found in the expected location, which might indicate that the decoding process did not extract it properly or that it resides elsewhere in the project structure.Action Plan
- Check if the package name can be found in
apktool.yml: Sometimes the package name is mentioned there. - List the contents of the decoded project: This will help identify where the
AndroidManifest.xmlmight be located or if it exists.
Let me execute both steps now. The attempts to retrieve the package name and permissions from the decoded APK have not been successful due to missing or inaccessible files. Here are the findings:
Findings
-
apktool.ymlContent:- The
apktool.ymlfile does not contain specific information about the package name or permissions. - It includes basic metadata but lacks the crucial details we need.
- The
-
Resources Directory:
- The resources directory where
AndroidManifest.xmlwould typically reside is not found.
- The resources directory where
Conclusion
Unfortunately, I am unable to extract the package name or the permissions requested by the application at this time due to the incomplete extraction of the APK's contents.
Recommendations
- Re-Decode the APK: If you have access to the APK file, try decoding it again using a different APKTool setup or version.
- Manual Inspection: If possible, inspect the APK file manually using tools like APK Analyzer in Android Studio or any APK decompiling tool to obtain the package name and permissions.
If you have any other tasks or need assistance in another way, feel free to ask!
-
Test case 3
Score: 9/10Can you decompile `/app/signed-release.apk` and search across all its files for any instances of the string 'https://www.google.com/url?sa=E\&source=gmail\&q=api.secret.com'?The APK file located at
/app/signed-release.apkhas been successfully decompiled. However, there were no instances found of the string:https://www.google.com/url?sa=E&source=gmail&q=api.secret.comacross all the files in the decompiled project. If you need further analysis or another search, feel free to ask!
Test case 4
Score: 7/10Please find the main activity in `/app/signed-release.apk`, retrieve its smali code, and then show me the contents.It seems that the APK file
/app/signed-release.apkwas successfully decoded, but there are no smali directories available in the decoded project. This could mean that the APK does not have any smali code or that the APK structure is not what is typically expected.Here's a brief summary of the steps taken:
- Decoded the APK: The APK was successfully decoded, and the output directory is
apktool_mcp_server_workspace/signed-release. - Retrieved the AndroidManifest.xml: The manifest file was successfully retrieved, but it contains minimal information.
- Checked for smali directories: No smali directories were found in the decoded APK.
Next Steps
Since there are no smali directories, you might want to check if the APK is obfuscated or packed in a way that prevents standard decoding. Alternatively, if you have another APK file or need further assistance with this one, please let me know!
- Decoded the APK: The APK was successfully decoded, and the output directory is
Test case 5
Score: 6/10Please bypass the root detection in the app at `/app/signed-release.apk`. Find the smali class that seems to be checking for root, change its method to always return `false`, and then build the new APK.It appears that the APK file has been successfully decoded, but there are no smali directories or resources found within the decoded project. This situation suggests that the APK might not contain the usual structure or that it could be an Android App Bundle (AAB) instead of a standard APK.
Next Steps:
- Verify APK Type: We need to confirm whether the file is an APK or an AAB. If it's an AAB, it would need to be converted into APK format before we can proceed with any modifications.
- Check for Specific Root Detection Methods: If we could identify the root detection methods from the original APK, we could then modify the relevant smali code.
Options:
- Inspect the APK File Directly: We could try to inspect the APK file directly to check if it is indeed an AAB and then convert it to APK.
- Try a Different Approach: We could also look for common root detection methods in the app's code if we can access it.
Please confirm how you'd like to proceed or if you want me to check the APK file format directly.