apktool-mcp-server

zinja-coder/apktool-mcp-server

4.4

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:

MCPHub score:4.42

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 Report
Total 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/10
    read 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/10
    What 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.apk has been decoded successfully. Here are the details:

    Package Name and Permissions

    1. Package Name:

      • The package name is not explicitly mentioned in the decoded information, but it can typically be found in the AndroidManifest.xml file.
    2. 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.xml file.

    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.xml file. Let me proceed with that. The extraction of the AndroidManifest.xml file did not yield the expected package name or permissions, as the manifest content returned seems to be incomplete or malformed.

    Summary of Findings:

    1. Package Name: Not directly available from the manifest extraction.
    2. 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.xml file 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 the AndroidManifest.xml file 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

    1. Check if the package name can be found in apktool.yml: Sometimes the package name is mentioned there.
    2. List the contents of the decoded project: This will help identify where the AndroidManifest.xml might 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

    1. apktool.yml Content:

      • The apktool.yml file does not contain specific information about the package name or permissions.
      • It includes basic metadata but lacks the crucial details we need.
    2. Resources Directory:

      • The resources directory where AndroidManifest.xml would typically reside is not found.

    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/10
    Can 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.apk has been successfully decompiled. However, there were no instances found of the string:

    https://www.google.com/url?sa=E&source=gmail&q=api.secret.com
    

    across all the files in the decompiled project. If you need further analysis or another search, feel free to ask!

  • Test case 4
    Score: 7/10
    Please 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.apk was 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:

    1. Decoded the APK: The APK was successfully decoded, and the output directory is apktool_mcp_server_workspace/signed-release.
    2. Retrieved the AndroidManifest.xml: The manifest file was successfully retrieved, but it contains minimal information.
    3. 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!

  • Test case 5
    Score: 6/10
    Please 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:

    1. 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.
    2. 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.