FAQ

This section summarizes some common issues and their solutions or workarounds. You should always verify and resolve problems using the latest version rather than tinkering with older versions.

  • Problem: The service fails to start normally, and the system crash information points to avtab or unsupported policy database format (selinux)

This situation may occur on Android 16, though it is not impossible on lower versions. First, be sure you are using the latest version of the server. If the problem persists, check whether the root solution you are using is KernelSU. The crash is caused by an older version of KSU corrupting the system SELinux policy image; try using the latest KSU version. If it still crashes, switch to Magisk or downgrade the shell permissions to run.

  • Problem: After running the service, the app cannot open, crashes, or is detected as abnormal.

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 work around this issue (side effect: Frida's spawn-related features become unavailable). In version 10.0 and above, this configuration item has been removed. Please upgrade to the latest version and contact us with specific details.

  • Problem: Q&A regarding packet capture features.

There is no need to ask whether the packet capture functionality is complete. FIRERPA has already taken care of everything and has performed all procedures required for packet capture. If other packet capture tools fail to capture packets, FIRERPA will definitely capture them; if FIRERPA cannot capture them, then no software using the same logic can capture them. Do not worry about certificate distrust issues – FIRERPA will automatically install a system-level root certificate for the app during capture; no manual operation is required. Regarding QUIC downgrade, startmitm automatically disables the UDP protocol. Normally, when an app cannot use UDP, it will automatically downgrade and not use QUIC, all without any manual intervention.

  • Problem: After running the packet capture script, no data packets are captured.

Possible causes: First, the app itself has certificate verification or certificate pinning mechanisms; second, improper pre- or post-processing. How to determine whether the app has certificate verification: enable global capture, then open a browser or other apps to see if capture works normally. Test several internet-connected apps: if some apps can be captured and others cannot, it is highly likely that the uncapturable apps use a proprietary protocol or certificate verification mechanism. This often leads to messages such as Client TLS handshake failed appearing in the startmitm log, but that is not the main point. Once it is confirmed that the app has certificate verification, you need to dynamically bypass the verification mechanism through reverse engineering or other methods in order to continue capturing. Regarding improper pre- or post-processing: typically, some users may not have disabled the system firewall, causing the proxy port to be unreachable from the phone without any response. Another situation is that the app already established necessary network connections before you started capturing, so the traffic after capture starts is still sent through these existing connections without going through the proxy. You need to manually force-stop the app completely after starting startmitm, and then reopen the app.

  • Problem: After using one-click capture, the phone appears to have lost network connectivity.

First, check whether the firewall is disabled. Second, when accessing a website from the phone browser, see if the one-click capture script outputs logs. If an error similar to No route to host appears and corresponds to the browser access (i.e., the script outputs this error on each access), then the likely cause is: the phone 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 on the script command line and test whether it returns to normal. If neither method works, contact support.

  • Problem: When using startmitm to capture packets, it continuously shows "error establishing server connection: No route to host" and the app has no network

This issue is the same as above. You can first test whether some other apps can be captured normally to rule out service issues. If proxying works normally, then this situation may be because the device supports IPv6, but 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 side.

  • Problem: The packet capture script shows "Client TLS handshake failed, does not trust the proxy's certificate"

If you can capture data packets from the relevant app normally, you can ignore this output. This is likely a log produced by the certificate verification mechanisms of other apps on the system or of a third-party SDK within the app.

  • Problem: After running the service, some detection tools detect anomalous characteristics.

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

  • Problem: I installed the autostart APK, but the service did not start normally and cannot be accessed.

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

  • Problem: When using the Python interface or packet capture, it consistently shows Service Unavailable

Please ensure you have completed the relevant configuration steps in the Environment Setup section, then try restarting the device multiple times (about 3 times). If the problem persists, make sure the device's network can normally access the public internet, and that the firewall is not blocking our authentication service (for this part, refer to the Privacy Statement section).