Recovering the SIM card PIN from the ZTE WF721 cellular home phone

As seen on Hackaday!

TL;DR – If you have a ZTE WF721 that’s PIN-locked your SIM card, try 2376.

Recently I picked up a used Samsung Galaxy Core LTE smartphone from a relative after they upgraded to an iPhone. As the Core LTE is a low-end smartphone, I suspected that the phone was SIM locked to its original carrier (Virgin Mobile), but in order to test this I needed a different SIM card. My personal phone was on the same carrier, so I wasn’t able to use that to test it.

However, the previous summer I picked up a ZTE WF721 cellular home phone base station (that is, it’s a voice-only cell phone that a landline phone plugs into), which came with a Telus SIM card. The issue is that the WF721 sets a SIM card PIN to essentially “lock” the card to the base station, and it wasn’t the default 1234 PIN; brute-forcing a SIM card is not possible as you get 3-5 attempts before the card needs to be unblocked using a PUK (PIN Unblock Key), failing that, the card is permanently rendered unusable. I decided to take the base station apart, and use my knowledge in electronics and previous research into smart cards to see if I could recover the PIN.

(Yes, I went through all this work instead of just buying a prepaid SIM card from the dollar store. I’m weird like that.)

Test Pads & Signals

After a bit of disassembly work involving removing screws hidden under rubber non-slip feet and a lot of spudgering open plastic clips, I got access to the four test pads that connect to the SIM card, accessible on the opposite side of the PCB from the SIM card socket.

ZTE WF721 Opened

The ZTE WF721 opened, with test pads broken out and connected to DSLogic for reverse engineering.

An ISO 7816-compliant smart card (and a SIM card is one) require 5 different lines to work: Vcc (power), ground, clock, I/O (data), and reset. The I/O is an asynchronous half-duplex UART-type interface, whose baud rate is determined by the card’s characteristics and the clock frequency that it is given by the reader (in this case, the WF721). The details of how the interface work can be obtained for free in their TS 102 221 specification from the ETSI (European Telecommunications Standards Institute).

ZTE WF721 SIM Card Test Pads

The test pads that connect to the WF721’s SIM card socket.

I then soldered the ground wire to a free test pad elsewhere on the board, whereas the four other wires were soldered to the test pads near the SIM card socket. I then connected these wires to a pin header and plugged it into my DSLogic Plus logic analyzer. I analyzed the logic captures after turning the WF721 on and allowing it to initialize the SIM card and attempt to connect to the cellular network (the service to it has been disconnected so it doesn’t actually succeed).

Command Analysis

After looking at the raw logic capture, there was a lot that I had to sift through. I needed to create a custom setting for the UART decoder as the serial output isn’t your traditional “9600-8-N-1” setting. Rather, the interface uses 8 data bits, even parity, and 2 stop bits. The baud rate is determined by a parameter in the card’s initial identification, the ATR (Answer to Reset). I parsed the card’s ATR that I previously captured on the PC using the SpringCard PC/SC Diagnostic tool using Ludovic Rousseau’s online tool, I determined I needed to use a baud rate of 250 kbit/s, since the card was being fed a 4 MHz clock.

T=0 Smart Card Command (APDU) Structure

The smart card communicates to and from the host through APDUs (Application Protocol Data Units). The command header for a T=0 smart card (character-based I/O, which most cards use) is made up of 5 bytes: class, instruction, 2 parameter bytes and a length/3rd parameter byte. To acknowledge the command, the card sends the instruction byte back to the reader and the data is transferred to/from the card, depending on the command used. The card then sends two status bytes that indicate whether the command is successful; if it is, the response is 0x9000. A graphical representation of this process can be seen in the next section.

VERIFY PIN Command Decoding

The raw data structure of a SIM card's VERIFY PIN command. Each part of the flow is labeled for ease of understanding.

The raw data structure of a SIM card’s VERIFY PIN command. Each part of the flow is labeled for ease of understanding (click image to see full size).

The command I’m looking for is 0x20 (VERIFY PIN), and I had to sift through the command flow in the logic analyzer until I found it. After a lot of preceding commands, I found the command I was looking for, and I found the PIN… and it’s in plaintext! As it turns out, it is sent as an ASCII string, but it’s not null terminated like a regular string. Instead, the data is always 8 bytes (allowing up to an 8-digit PIN), but a PIN shorter than 8 digits will have the end bytes padded with 0xFF (all binary ones). It was easy to determine that the bytes 0x32 33 37 36 is the ASCII representation of the PIN 2376, and after the card waited many tens of milliseconds, it acknowledged the PIN was correct as it gave the expected 0x9000 response code.

PIN Testing & Unlocking

SIM Opened in Dekart SIM Manager

Dekart SIM Manager showing the phone number programmed into the SIM card (censored for privacy).

I tried the PIN in the Dekart SIM Manager software on my computer, and it worked! I was able to read out the contents of the SIM and find out what phone number it used to have, although no other useful information was found.

By using the legacy GSM class 0xA0, I was able to manually verify the PIN by directly communicating with the SIM card using the same command syntax in PC/SC Diagnostic:

SIM Card VERIFY PIN Test

Testing the VERIFY PIN command directly in SpringCard PC/SC Diagnostic.

I took the SIM card out and put it in my Galaxy Core LTE phone, entered the PIN, and as expected it brought up the network unlock prompt. I was able to contact my carrier to get the phone unlocked, and they did it for free (as legally required in Canada) – it turned out to be helpful I was on the same network, as they needed an account to authenticate the request against, even if the phone is registered to another account holder. After entering the 8-digit unlock PIN they provided, the phone was successfully unlocked!

The WF721 is in all likelihood also network locked, but that’s a bridge I haven’t crossed yet.

Conclusion

After a bit of sleuthing into how SIM cards communicate with a cell phone, I was able to decipher the exact command used to authenticate a SIM card PIN inside a disused cellular home phone, all to check if a hand-me-down smartphone was network-locked to its original carrier. Was it a lot of effort just to do that? Maybe, but where’s the fun in buying a prepaid SIM card? 🙂

Tutorial: Recovering Cookie Clicker saves from an offline installation/backup of Google Chrome

Update (August 29, 2018): Turns out cleaning out your cookies/cache wwill erase your Cookie Clicker save. Who would’ve thought…

Cookie Clicker saves: You don’t realize the importance of saving your progress until you lose your save data. A few days ago I opened Chrome to my always-running instances of Cookie Clicker, but found that all of my progress was deleted (and it was showing a “Don’t forget to back up your save” message just to add insult to injury).

My heart sank when I realized that one of my runs, over three years old, had suddenly vanished into thin air. I tried restoring Google Chrome’s data via a Shadow Copy; no dice. I tried using my Windows Home Server 2011 backups, but realized that it would take over an hour to restore my Chrome folder. After much frustration, I decided to retrieve and examine Chrome’s Local Storage folder and see whether I could retrieve my save files that way – and it worked! Here’s how to recover your own Cookie Clicker saves…

Retrieving an older version of Google Chrome’s data folder

If you have Shadow Copy (aka Previous Versions) enabled, you may be in luck if the restore point(s) available have intact game save information. If you have an offline backup solution, that may be usable as well. If you have neither, you could try it on your current Chrome installation but your chances of recovery are much slimmer.

For Windows, Google Chrome’s default Local Storage folder located at: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Local Storage

There will probably be a large number of files ending in .localstorage and .localstorage-journal – these are unlikely to contain your saves, and if they are present, they will be many months out of date; Google has begun storing websites’ local storage in a LevelDB database. The database in question is stored in a folder called leveldb.

If you are attempting to retrieve the data from a current Chrome installation, close Chrome before continuing.

Copy this “leveldb” folder to another (safe) location as to avoid any accidental overwrite of the database while trying to recover the game saves. Download and install the FastoNoSQL database browser software (it’s a trial, but for our purposes it will do just fine – just follow the registration instructions and you can whip up a temporary email address if you need to).

Browsing the LevelDB database

When FastoNoSQL is opened for the first time, the Connections window will appear. Click the “Add connection” button (it looks like a green button with a + symbol on it); even though we’re just browsing some database files, it’s considered to be a “connection” to the database. Select “LevelDB” and choose the folder that holds the “leveldb” folder that was previously copied.

 

Once the database is opened, note the number of database keys (in my case it was 1212), right-click the “default” database in the Explorer tree on the left-hand side of the FastoNoSQL window, and select “Load content of database”. Enter the number of keys previously noted into the “Keys count” field, then click OK.

 

In the “Search…” box, enter this text (select all the text in this box):

\\x5f\\x68\\x74\\x74\\x70\\x3a\\x2f\\x2f\\x6f\\x72\\x74\\x65\\x69\\x6c\\x2e\\x64\\x61\\x73\\x68\\x6e\\x65\\x74\\x2e\\x6f\\x72\\x67\\x00\\x01\\x43\\x6f\\x6f\\x6b\\x69\\x65\\x43\\x6c\\x69\\x63\\x6b\\x65\\x72\\x47\\x61\\x6d\\x65

This cryptic-looking text is a hexadecimal-escaped version of the string _http://orteil.dashnet.org, an SOH (Start of Header) character, and CookieClickerGame.

If your saves are found, you will see one or two entries, depending on whether or not the normal and/or Beta saves are present. The first entry will be the normal version of Cookie Clicker, and the second one, with a slightly longer key (ending in “\x42\x65\x74\x61”) is the for the Beta. Right-click the desired entry and choose “Edit…” to view the game save data. Copy the contents of the “Value” field into a text editor (Notepad, etc.), and delete the very first character before “Mi4w” – this is an SOH (Start of Header) character and we don’t need it to restore the game save. Save this text file so you have a backup of your game save, and import the file into Cookie Clicker (either by copy-pasting the text or using the “Load from file” button).

 

The game save should look like this (look for the bolded characters to ensure the game save data is intact):
Mi4wMDQ1fHwxNTI [... text omitted ...] OkwoDCgAR8%21END%21

If everything works out, your Cookie Clicker game save should be restored from the brink of destruction!