Issue 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 cause this issue in some environments. Please switch to the latest version.

This may occur on Android 16, but it is not ruled out on lower versions. First, make sure you are using the latest server version. If the issue still occurs, check whether the root solution you are using is KernelSU. The crash occurs because an old version of ksu corrupted the system SELinux policy image. Please try the latest 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. You can try configuring enhanced-stealth-mode=true in the remote desktop to avoid this issue (the side effect is that Frida spawn-related features cannot be used). In 10.x, by default you do not need to set this option; the default frida-server version used by 10.x already avoids this issue. (However, if you manually switch to version 17.5.2, you may need to configure this option.)

There is no need to ask whether the packet capture feature is complete. FIRERPA has arranged everything and has already completed all the processes required for packet capture. If other packet capture software you use cannot capture packets, FIRERPA will definitely be able to capture them; if FIRERPA cannot capture them, then no software with the same logic can capture them. There is no need to worry about certificate trust issues. FIRERPA will automatically install a system-level root certificate for the application during packet capture, without any manual operation. For QUIC downgrade, startmitm will automatically disable the UDP protocol. Normally, when an APP cannot use UDP, it will automatically downgrade and not use QUIC, all without requiring manual intervention.

Possible reasons: first, the APP itself has a certificate verification or certificate pinning mechanism; second, the pre- and post-processing was not performed correctly. How to determine whether the APP has a certificate verification mechanism: enable global packet capture, then open a browser or other APP to see whether packets are captured normally. Try several networked APPs to confirm: if some apps can be captured and others cannot, then it is likely that the apps that cannot be captured use a private protocol or certificate verification mechanism. This usually outputs messages such as Client TLS handshake failed in the startmitm log, but this is not the key point. If you confirm that the APP has certificate verification, you should dynamically bypass the verification mechanism through reverse engineering or other means to continue capturing packets. Regarding incorrect pre- and post-processing: usually, some users may not have disabled the system firewall, causing the proxy port to be inaccessible from the phone and no response at all. Another situation is that the APP has already established necessary network connections before you start packet capture, so traffic after the capture starts is still sent through these existing connections and does not pass through the proxy. You need to manually fully close the APP (force stop) after starting startmitm, and then reopen the APP.

First, check whether the firewall is disabled. Second, check whether the one-click packet capture script outputs logs when accessing websites from the phone browser. If an error similar to No route to host appears and corresponds to the browser access action (that is, the script outputs this error each time you access a website), then 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 IPv6, causing 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 whether it recovers. If neither method works, please contact support.

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

If you can capture the relevant application's packets normally, you do not need to worry about this output. It may be log generated by the certificate verification mechanism of other APPs in the system or the APP's third-party SDKs.

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

The auto-start APK is subject to the settings of different systems and may not start automatically with the system. If it cannot be accessed after boot, please click the Manual Start button in the APP to start it manually, wait one minute, and then try again. If it still cannot start, please try manual installation or module installation.

Please make sure you have completed the related settings in the Environment Preparation section, then try restarting the device several times (about 3 times).