04. FAQ & Known Issues - Theliel/SMSForge GitHub Wiki

FAQ & Known Issues

This section addresses the most frequent questions regarding SMS Forge’s usage, legality, and requirements, as well as offering solutions for common errors related to hardware compatibility and PDU configurations.


Frequently Asked Questions (FAQ)

1. Why do I need Root permissions to use SMS Forge?

Answer: Standard Android APIs for SMS transmission do not provide the necessary low-level access to construct and send fully customized PDU messages with advanced flags. To achieve granular control over cellular communication and the PDU layer, the application must bypass these APIs and interact directly with the modem hardware (baseband). Accessing the device files (such as /dev/smd* or /dev/at*) that allow sending AT commands directly to the modem requires Superuser (Root) permissions.

2. Besides Root, is any Magisk module or framework required?

Answer: No. SMS Forge only requires that your system’s Root manager (such as Magisk or SuperSU) grants it permissions. No Magisk module, Xposed, or any other additional framework is needed for core functionality.

3. Is the use of SMS Forge legal?

Answer: The legality of the application depends entirely on the legislation of each country and the use the user gives it. SMS Forge is a technical tool that allows manipulation of the GSM/SMS protocol.

  • The Tool Itself: Generally, technical tools are not illegal.
  • The Use: The user is solely and fully responsible for the lawful or unlawful use of the application. I strongly advise against any malicious, fraudulent, or illegal use of the application.

4. Why is my Flash SMS (Class 0) not displayed correctly?

Answer: The behavior of Flash SMS messages can vary dramatically because the decision on how to display or manage it falls to the receiving device’s firmware, not the message itself.

  • Variable Behavior: On some devices, it appears immediately; on others, it may not appear, omit the sender, or even ask the user to save it.
  • Reason: Manufacturer software layers and frameworks often manage and can modify the default behavior of the Class 0 standard, based on security or user experience policies. On iOS, for example, the message will appear directly on the screen without a sender and without the option to save it; on Android, it can usually be saved, and the sender will become visible if it is saved.

5. Does the Status Report (TP-SRR) really work?

Answer: It works with limitations. For the status report to function correctly, the receiving device’s baseband must allow the reception of this type of message directly through AT commands.

  • Common Issue: Many modems are configured to exclusively capture and manage status reports through the operating system (Android) and do not expose them via the device files, which hinders their direct reception by SMS Forge.
  • Future: Different approaches are under development to solve this almost definitively, improving delivery confirmation reliability.

6. My Self-Destruct SMS do not seem to delete after being read. Why?

Answer: Similar to Class 0 messages, the self-deletion function depends on how the recipient’s modern framework handles incoming SMS.

  • Functionality Overwrite: Modern operating systems often “overwrite” some inherent PDU standard functionalities, such as SMS storage, management, and deletion. The framework may save the message to a database before the self-deletion flag is processed.
  • Conclusion: Although SMS Forge correctly sends the Auto-Deleted flag, the final behavior relies on the recipient’s messaging software implementation.

7. Why do some “mix” configurations not work or have unexpected behavior?

Answer: SMS Forge is designed to be flexible and grant maximum control, avoiding forcing default values simply because an option is activated.

  • Research and Flexibility: This allows security users and researchers to explore combinations of settings that standard applications do not permit.
  • Consequence: The immense control over PDU settings means that certain combinations may have unexpected behavior on the receiving device or be directly rejected by its firmware (see Modem Compatibility section).

8. Why do some options disable others?

Answer: The application only disables options when they are mutually exclusive within the GSM/SMS protocol.

  • Exclusion Examples:

    • To send Replacement or Silent messages (Type 0), the TP-PID must be configured as SME2SME (Simple Text Message Protocol).
    • If MWI is used via the DCS method, the SMS Class nor the Auto-Deletable SMS can be used simultaneously.

9. What features are missing or can be expected?

Answer: SMS Forge originated as my personal project, and I have implemented the functionalities that interested me most as free time permitted. There are still several interesting functionalities in the pipeline. If you have a feature request that you think might be interesting and feasible, please open a new bug report with the request. I will evaluate it accordingly.

10. Why my device’s list are empty?

Answer: First, make sure the app has root permissions. If no devices are listed, you can try forcing a refresh. The easiest way to do this is through the app’s settings, by tapping Reset → Devices.

If nothing appears after trying this, it’s very possible that the app’s current logic isn’t able to find any access to the modem on that device. This doesn’t necessarily mean it’s not working. To troubleshoot, enable app debugging in settings and send the log file. Then, restart the app and send the log file to us via email.

11. None of the listed modems are compatible after checking

Answer: The application is unable to find a modem access device; this does not mean it doesn’t exist. Please note that it’s impossible to check every model/manufacturer. As new patterns and access devices are detected, the application will be updated accordingly. If the application has been recently updated, check the changelog to see if compatibility has been expanded, and force a refresh of the detected devices by going to Application Settings and tapping Reset → Devices.

Alternatively, please feel free to send me the debug file from the application (after enabling the debug option and restarting the application).


Known Issues

This section will be expanded as specific SoC and model issues are identified.

⚠ Error: “Failed to obtain /dev/* access”

  • Cause: The application failed to find a compatible device file to communicate with the modem or was not granted the necessary Root permissions.
  • Solution: Ensure your device is correctly rooted and that you have granted persistent Root access to SMS Forge. If the error persists, your modem likely does not expose the communication interface in a way the application can detect and access or SMS Forge cannot find it. Send a debug log to see if implementation is feasible.

⚠ The configured Service Centre (SMSC) is ignored.

  • Cause: The device’s baseband is internally forcing the use of the default SMSC from your SIM or system, ignoring the value specified in the PDU (see Modem Compatibility section).

MWI does not work on the receiving device.

  • Cause: The recipient device’s framework (or the voicemail/messaging application) may be designed to look for MWI notifications only through operator-specific system messages, or it may be misinterpreting the DCS/UDH fields of the MWI generated by SMS Forge.

⚠Only the first MMS notification works for the same recipient.

  • Cause: Some devices can only handle a single MMS notification message, and until the content is fully downloaded, the next one won’t be processed. This is a problem because even if we can send the notification, and even if we specify the URL of the resource to download, it won’t work! Accessing MMS content generally requires our mobile operator’s network, which connects to specific operator servers to access the content. This, in turn, means that the recipient of our notification can’t actually access the intended content, receives an error, and maybe don’t process any further MMS messages.
  • This means that if we send an MMS notification SMS to any destination the first time, it will work perfectly, but if we send a second one and they haven’t deleted the first, they might not receive it in their message inbox.

WAP Push (SL/SI) SMS are largely ignored or blocked by modern smartphones.

  • Cause: Modern mobile operating systems (like Android and iOS) treat WAP Push messages with high suspicion. Historically, these messages allowed automatic loading of URLs or data, posing a significant security risk (e.g., drive-by downloads or phishing). To mitigate this, most modern devices now silently process, convert into passive text notifications, or completely ignore them.
  • Modern Device Behavior: While some Android devices may still process the WAP Push content to generate a simple notification, they strictly prevent automatic URL launching. The user must manually click a link within the notification to navigate, which defeats the historical purpose of the “push” mechanism.
  • iOS Specific Limitation: Apple’s platform applies the most stringent filtering. iOS devices typically discard WAP Push SMS messages outright at the device level, considering them an obsolete or insecure feature. As a result, WAP Push messages sent to an iPhone will almost never result in a visible notification or action on the recipient’s device.
⚠️ **GitHub.com Fallback** ⚠️