SIMTester assess SIM card security in two dimensions:

• Cryptanalytic attack surface: Collect cryptographic signatures and encryptions of known plaintexts
• Application attack surface: Generate a list of all application identifiers (TAR) and find "unprotected" (MSL=0) applications

• Java 1.7+
• PC/SC reader (via pcsc daemon) –or–
• Osmocom phone (via libosmosim)

java -jar SIMTester.jar <arguments>

In case Java has problems to find the libpcsclite shared object, just submit the path manually (adjust it to your system):

java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -jar SIMTester.jar <arguments>

Has its own intelligent logic, fuzzes ~130 chosen TARs, is divided into 3 modes:

• Full fuzzing (default) - all 15 keysets with all 16 fuzzing mechanisms
• Quick fuzzing (-qf option) - keysets 1 to 6, only 4 most successful fuzzing mechanisms
• Poke the card (-poke option) - same as quick fuzzing but only fuzzes 3 most common TARs (000000, B00001, B00010)

Custom keysets and TARs can be specified via -t and -k parameters (space being a delimiter between multiple values).

In addition to this the user has the option to keep certain bytes constant during fuzzing:

OTA messages are delivered over SMS with standard PID, DCS, UDHI, IEI/CPH parameters. Service providers usually will filter OTA messages by their parameters and will usually comply with the standard to make up their filter rules. Using the OTA-Passthrough fuzzer functionality, the user can check if there are alternative, undocumented parameters which can be used to get the OTA message through. If undocumented parameter constellations are found, its very likely that they are not filtered by the service provider, which would be a weakness.

The response handling of OTA-Messages can be implemented in two different ways. The backend either expects an additional user data field in the SMS-DELIVER-REPORT or waits for an incoming SMS that the card issues (SMS-SUBMIT) after completing the requested operation. The user can use the following option to choose between these to methods:

Scans for valid TAR values by sending messages to them, has 3 modes:

• Full scan (-st option) - scans for all possible TAR values (0x000000 - 0xFFFFFF) - may take a few hours or several days depending on your SIM card speed
• Ranged scan (-str option) - scans for valid TAR values in pre-specified ranges to optimise the scanning duration

In addition to the scan type, some options can be specified:

• Smart TAR scan (scan a few random TARs to determine false response, option -stbs)

Use a specified REGEXP to match response for false positives (option -stre).
Normally false responses should be constant (PoR status or status word), but there are corner cases in which also false responses might contain variable data.

A starting value for Full scan can be specified using -t option.
A keyset used for sending messages can be specified using -k option (for both Full and Ranged scans).

Tip: run fuzzer first, see what keysets seem responsive (give answers other than none) and use one of those for TAR scanning, because if you use an inactive keyset it's very probable the card will NOT answer even on a valid TAR which makes TAR scanning non-functional.

Scans for valid APDU values (think of APDUs as of commands to the card) on TARs without any public APDU reference, it has 2 modes:

• LEVEL 1 scan (performed automatically after Fuzzer finishes and has found unprotected TARs with responses) - only scans for valid CLA 0x00 - 0xFF - it is performed via OTA messages. Can also be invoked manually (option -sa)
• LEVEL 2 scan (option -sa -sal2) - scans for both CLA 0x00 - 0xFF and INS 0x00 - 0xFF - it is performed locally on card I/O on initially selected application

Automatically scans the files present on the SIM. This option can be used to detect non standard, proprietary files on the SIM. The scanner will start at 3F00 and automatically skips reserved values. The user has the option to add additional reserved values in order to skip files in case of problems. It is also possible to run the scanner in standard-scan-mode where only standard files are checked for their presence.

Upload the results to gsmmap by using the -gsmmap option.

Tor can also be specified:

java -jar SIMTester.jar -gsmmap -socksProxyHost=127.0.0.1 -socksProxyPort=<tor_port> ... other options ...

If you already have scanned your cards without -gsmmap option, you can use the web form to upload your CSV results provided by SIMTester.