FAQ Summary¶

Please download this script user-home/modules/script/enhanced_automation_wechat.yaml and place it in the device's ~/modules/script directory.

Older versions may have this problem in some environments. Please switch to the latest version.

This situation may occur on Android 16, but lower versions are not excluded. First, please ensure you are using the latest version of the server. If the problem persists, check if the root software you are using is KernelSU. The crash is because an older version of ksu damaged the system's SELinux policy image; please try using the latest version of ksu. If it still crashes, switch to Magisk or run with downgraded shell permissions.

This may be because some APPs use app-zygote to detect Frida. In versions below 10.0, you can try configuring enhanced-stealth-mode=true in properties.local to circumvent this issue (the side effect is that Frida's spawn-related features cannot be used). Version 10.0 and above have removed this configuration item. Please upgrade to the latest version and contact us with specific feedback.

There is no need to ask whether the packet capture function is perfect; FIRERPA has arranged everything, and it has already completed any process required for packet capture for you. If other packet capture software you use cannot catch packets, FIRERPA will definitely catch them; if FIRERPA cannot catch them, then no software with the same logic can. Don't worry about certificate trust issues; FIRERPA will automatically install a system-level root certificate for the application during packet capture, without manual operation. For QUIC downgrade, startmitm will automatically disable the UDP protocol; normally when the APP cannot use UDP, it will automatically downgrade and not use QUIC, all of which require no manual intervention.

Possible reasons: First, the APP itself has a certificate verification or certificate pinning mechanism; second, the pre- and post-processing was not done correctly. How to determine if the APP has a certificate verification mechanism: enable global packet capture, then open the browser or other APPs to see if they capture normally. Test several internet-connected APPs to confirm: if some apps can be captured and others cannot, it's highly likely that the apps that cannot be captured use proprietary protocols or certificate verification mechanisms, which usually output Client TLS handshake failed and other information in startmitm's logs, but this is not the focus. If you confirm the APP has certificate verification, you need to dynamically bypass the verification mechanism through reverse engineering or other means to continue capturing. Regarding incorrect pre- and post-processing: Normally, some users may not have disabled the system firewall, causing the proxy port to be unreachable by the phone without any response. Another situation is that the APP established necessary network connections before you started capturing, so the traffic after capturing still uses these existing connections without going through the proxy. You need to manually force close the APP after starting startmitm, then reopen it.

First, check if the firewall is disabled. Second, check if the one-click packet capture script outputs logs when accessing websites from the phone's browser. If an error like No route to host appears and corresponds to the browser access (i.e., the script outputs this error every time you access a website), the possible reason is: the phone itself supports IPv6 network access, and the default DNS resolution also uses IPv6, but the computer running the script does not have IPv6 enabled or does not support it, resulting in No route to host. If your broadband supports IPv6, manually enable it in the computer's network settings; or try specifying --proxy-dns 114.114.114.114 in the script command line and test if it returns to normal. If both methods are ineffective, contact support.

This issue is the same as the above. You can first test if other APPs can be captured normally to rule out service issues. If they can be proxied normally, then this situation might be because the device supports IPv6, but the machine running startmitm does not have a valid IPv6 address. If your network has a usable public IPv6, assign one to your computer; or completely disable IPv6 on the router.

If you can capture data packets from the relevant app normally, you don't need to worry about this output; it may be logs generated by the certificate verification mechanism of other system APPs or third-party SDKs in the APP.

Please confirm that this problem only occurred after starting FIRERPA. If confirmed, and the issue persists after upgrading to the latest version, contact us. (The enhanced-stealth-mode configuration has been removed since version 10.0 and is no longer applicable.)

The auto-start APK, limited by different system settings, may not automatically start with the system. If it cannot be accessed after booting, manually start it by clicking the Manual Start button in the APP, wait for one minute, and then try accessing again. If it still cannot start, try manual installation or module installation methods.

Please ensure you have completed the relevant setup in the Environment Preparation section, then try restarting the device several times (about 3 times).