04. FAQ & Known Issues - Theliel/SMSForge GitHub Wiki
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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).
- 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.
- 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).
- 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.
- 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.
- 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.