As you may know, OTA messages or Over The Air messages, are specially crafted binary SMS messages which are used by mobile operators to send APDU commands to the SIM cards for managements purposes. They can use this type of messages to install or delete applets on/from the SIM cards for example.
I want to know if is there any public document that illustrated format and structure of these messages from bottom up?! In the other words: Is there any specification[s] which I can use to craft an OTA message based on it?
I know that OTA messages are usually signed by keys which only provider may have them, but I heard that some of them don't require any signature.
Targeted device have the ability to receive a SMS that contains a set of U(SIM) Application Toolkit Commands (3GPP TS 31.111 Universal Subscriber Identity Module (USIM) Application Toolkit(USAT)). A SMS that contains these commands is
commonly referred to as an OTA (Over The Air) SMS.
These are specific type of an OTA SMS, destined directly for the SIM Card (SIM OTA SMSs). The set of Application Toolkit Commands themselves are stored in the Secured Data (3GPP TS 31.115 Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications) section of the STK Command Packet, which itself is enclosed within the TP-UD(3GPP TS 23.040 Technical realization of the Short Message Service (SMS)) parameter within a SMS-SUBMIT or SMS-DELIVER , that make up the SMS.
To send this kind of messages you can use the Osmocom project is an umbrella project regarding Open source mobile communications. This includes software and tools implementing a variety of mobile communication standards, including GSM, DECT, TETRA and others.
Brief History
The OTA specification, GSM 03.48, was first created for Release 97 of GSM.
GSM 03.48 “Security Mechanism for the SIM application toolkit” defines:
The structure of the secured packets in SMS-PP (Point-to-Point) and
SMS-CB (Cell Broadcast)
The set of commands for Remote File Management on the SIM
The set of commands used for Remote Applet Management for SIM cards
compliant with 03.19 (i.e. JavaCard cards)
GSM 03.48 was renamed 3GPP TS 23.048 for Rel-4 and Rel-5 and is applicable to both GSM and 3G.
For Rel-6 TS 23.048 is split into 4 specifications:
ETSI TS 102 225
ETSI TS 102 226
3GPP TS 31.115
3GPP TS 31.116
The features applicable to any telecommunication environment are transferred to ETSI SCP
(ETSI TS 102 225 and TS 102 226), while the 3GPP specific parts are kept in 3GPP TS
31.115 and TS 31.116.
ETSI TS 102 225 “Secured packet structure for UICC based
applications” Defines the secured packet structure.
ETSI TS 102 226 “Remote APDU Structure for UICC based applications”
Defines the set of commands to make Remote File Management and Remote
Application Management. Those commands are transported in the secured
packets as defined in TS 102 225.
3GPP TS 31.115 “Secured packet structure for (U)SIM Toolkit
applications” Is the mapping of the secured packets on SMS.
3GPP TS 31.116 “Remote APDU Structure for USIM Toolkit applications”
Contains the SIM/USIM specific features for remote file management
and remote applet management.
Related
I am planning to design a simulator which mimics complete UE attachments and registration in 5G core network. Since N1 is a logical interface, how the NAS message is transmitted from the UE to RAN to AMF (At its core transfer protocol SCTP is used between RAN and AMF)? Any sample packet capture would also help.
Yes, you are right, SCTP protocol is used between AMF and gNB (RAN) just like in lte.
There is RRC protocol between UE and gNB.I do not have much knowledge in this area. But for registration this part is not important, and I think you can just send NAS as raw package to gNB.
After that, gNB put NAS-5G message (registration request in your case) from UE, to NGAP (N2) transport message, and sends it via SCTP.
I recently aquired a Segway Ninebot ES2 electric scooter. I can connect to the scooter via Bluetooth LE and grab information such as battery status, current mileage, temperature, and so on. This is all done through an application.
On my Android device, I've successfully extraceted the HCI log file, which I imported into Wireshark. I can see all the requests and commands send back and forth between my phone and the scooter. However, the requests and responses are all garbage and I have no idea how to interpret them.
Example of a sent command (info says Sent Write Command, Handle: 0x000e (Nordic UART Service: Nordic UART Tx))
Example of the received value I got right after (info says Rcvd Handle Value Notification, Handle: 0x000b (Nordic UART Service: Nordic UART Rx))
How am I supposed to interpret these responses? If the battery status was 59%, I would expect it to return something like 0x3b (0x3b hex is 59 decimal). But honestly, I have no idea how this works. Maybe they're returning a bunch of data in a data type only their app knows how to interpret? Like JSON for web.
Here's an example from the nRF Connect for Mobile application, where I hit the down arrow on all the characteristics: https://i.imgur.com/hREDomP.jpg (large image)
And probably more important: How do I replicate a request or command in nRF Connect? I've tried sending a byte array that looks like 0x {02410011000d.....} (from the Write Command) in the application, but I have no idea how to read the response.
If someone is still interested, I did the same research for this scooter.
That's standart BLE communacation, device offers BLE "services" and "characteristics". Service can contain one or more characteristics, by which you communicate with device. Each charateristic can allow different types of interaction with it: writing into it, reading from it, subscribing to notifications (so you dont have to to manually read, it kinda pushes data to your app), and more (read here, for example)
Take a look at your wireshark screenshot: you can see Service UUID, Handle UUID (the characteristic), and handle ID. You can communicate with device via uuid or id, depending on your programming language or library (more about uuids).
In this particular scooter there are two characteristics, one allows writing into it, another - allows subscribing to it. Together, they act like RX and TX wires in UART: you write data into one and read from another. So, to begin communication with scooter you must establish connection to it, subscribe for notifications from one ch, and write data to another.
As for protocol: look again at she screenshots, "UART Tx" is the actual payload that was sent to scooter and "UART Rx" was the response. Yes, it's binary data, that only app would understand. Luckily, protocol has been reverse engineered and is well documented. In your example app requests serial number, and it's returned in response - "N2GWX...". In order to request battery percentage you must build another payload according to protocol.
I'm not sure if it's still relevant, but at least for those, who will be interested in the topic.
You can try the following to understand how to interpret response from the device.
An option to consider is to fetch manufacturer's mobile app (apk) either by adb or from sites like apkmirror, etc.
Then apply some reverse-eng tool like JADX.
If you're lucky and the code is somewhat readable, then search for smth that has to do with response (like ResponseParser) and try to find algo that is used to interpret the response.
However, the very first attemp should always be to search on github/google if smb did it already for your device, unless it's very niche.
I want to perform RMI , to an applet via SMS. My applet will process an APDU sent via the SMS and it will call a method depending on the APDU. I cannot find a method to achieve this.As per my reserch this depends on the card manufacturer and is not supported by all OS's. Is there any framework or technique which can help us to achieve the required result ?
#Abhirup Ghosh: This is possible, search for NowSMS and Open Kannel.
Using these tools and GSM Modem, i have created utility that sends SMS to JAVACARD applet which processes the sms and gets the APDU in it.
You have to change your SMS Class and TYPE so that the OS of card treat it as envelope and pass it to the JAVACARD application.
You can also refer this paper:
http://www.ijsrp.org/research-paper-0415/ijsrp-p4024.pdf
I am analyzing the traffic beacons generate using tshark and iptraf. I know they are mainly used to determine the proximity of a device and like any other network device the traffic generated by them must be having a header and payload information in it.
What is best way to find out the payload information though header info can be identified as to where packet is being sent etc , but how we can classify the payload and what information it contains in a beacon signal , is it the same like any other web traffic sent and receive on a network or is it different since they make use of Bluetooth ?
Any pointers regarding would be useful .
Bluetooth LE beacon transmissions are much simpler than the HTTP protocol. They are transmit only and have no real headers, although there are short segments within the transmissions called PDUs that have a similar purpose.
To see an example of a beacon transmission, see my answer here:
What is the iBeacon Bluetooth Profile
What is the SMPP protocol and how does it work?
I've not even seen it yet and have to start with introduction onward.
SMPP is a low-level binary Internet protocol.
The primary use of SMPP is to send and receive medium-to-high volumes of SMS texts.
SMPP uses a standard Internet connection to connect to an SMPP provider, to do away with or compliment the purchase of a GSM modem or a SIM card.
SMPP offers the following benefits over a GSM modem:
Send by a meaningful name e.g. a company name instead of phone number.
Send by a short codes; 3, 4, or 5 digit phone number instead of the normal length.
Faster processing
Software:
Kannel is an open-source client for experimenting on.
ActiveXperts Mobile Messaging Toolkit is a commercial solution with SMPP simulator.
For the record: I'm a programmer at ActiveXperts, actively involved in SMPP and SMS related developments.
Fundamentally it's the main protocol that SMS aggregator companies
(mostly!) use when communicating with different type of Gateways (GW).
Please check these links...they will definitely help you out understand SMPP more thoroughly.
http://www.simpleteam.com/downloads/SMPP_v3_4_Issue1_2.pdf
http://www.ehow.com/facts_7344160_smpp-protocol_.html
Wikipedia definition:
"SMPP is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centers and/or External Short Messaging Entities. It is often used to allow third parties (e.g. value-added service providers like news organizations) to submit messages, often in bulk."