FAQ¶

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

Old versions may cause this issue in some environments. Please switch to the current latest version. If the problem persists, disable all Magisk modules and reboot.

This may occur on Android 16, but lower versions are not excluded. First, make sure you are using the latest server version. If the problem persists, check whether the root solution you are using is KernelSU. The crash occurs because an old version of ksu has corrupted 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 privileges.

The default frida version used by 10.x may have issues on some lower Android versions. Because the injection logic updated in frida 17.6.x and later causes some apps to fail to be injected properly, or there are compatibility issues and script errors on older installations, starting from version 10.8, the server ships with two versions of frida-server. By default, the latest frida-server is always used. If you encounter the above issues, you can configure frida.version=17.5.2 to specify using the older frida-server version.

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 problem (the side effect is that Frida's spawn-related features cannot be used). In 10.x, by default you do not need to set this option, because 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.) If the problem persists, disable all Magisk modules and reboot.

There is no need to ask whether the packet capture feature is complete; FIRERPA has already arranged everything and has completed all the processes required for packet capture for you. If other packet capture software you use cannot capture packets, FIRERPA can definitely 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 distrust. FIRERPA will automatically install a system-level root certificate for the app during packet capture, with no manual operation required. For QUIC downgrade, startmitm automatically disables the UDP protocol. Normally, when an app cannot use UDP, it automatically downgrades and does not use QUIC. All of this requires no manual intervention.

Possible reasons: first, the app itself has a certificate validation or certificate pinning mechanism; second, the pre- and post-processing was not performed correctly. How to determine whether the app has a certificate validation mechanism: enable global packet capture, then open a browser or other apps to see whether packets are captured normally. Try several networked apps to confirm: if some apps can be captured and others cannot, then the apps that cannot be captured most likely use a private protocol or certificate validation mechanism. This usually outputs messages such as Client TLS handshake failed in the startmitm log, but that is not the key point. If you confirm that the app has certificate validation, you need to dynamically bypass the validation mechanism through reverse engineering or other means before you can 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 resulting in no response. Another situation is that the app has already established necessary network connections before you started packet capture, so traffic after packet capture starts is still sent through these existing connections instead of going through the proxy. After starting startmitm, you need to manually completely close the app (force stop), and then reopen the app.

First, check whether the firewall is disabled. Second, check whether the one-click packet capture script outputs logs when visiting websites in the phone browser. If an error similar to No route to host appears and corresponds to the browser access action (that is, each visit causes the script to output this error), then the possible cause 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, resulting in No route to host. If your broadband supports IPv6, manually enable it in the computer 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, 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 problems. 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 packets from the relevant app normally, you do not need to care about this output. It may be log entries generated by the certificate validation mechanisms of other apps in the system or by third-party SDKs in the app.

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

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