SYSCFG is an area of storage on the iPhone that persists following a clean DFU device restore. This is absolutely necessary for many hardware-control related values, such as the Device Serial Number. Just to clarify because i’ve had a few questions about this - MagicCFG is a GUI front end to interface over serial. SYSCFG is the actual area of storage on the device holding these values. If you’re just editing a single value, its much safer to do it yourself over serial as we do in this article, As parsing errors can occur with the GUI clients and potentially break functionality on your iDevice. Let’s proceed!
There are so many reasons not to modify this value - more than I can fit into this article.
There is also one reason why you should modify this value. Aesthetics, and bragging rights - Obviously!
Serial modifications can cause multiple issues with the device functionality, for example, potentially breaking device restores. The iOS Device Restore Process, to my knowledge, submits your device ECID (Permentantly Embedded In The SoC) and Serial Number, during a traditional device restore. These two values must match in order for a valid SHSH2 blob to be generated and allow for the device to succesfully restore.
A good friend of mine @technoexplorer has kindly clarified my rough understanding of the Serial and ECID being submitted. The correct explanation is 'A single hash of the Serial and ECID is sent to Apple for verification.'
However - A good friend of mine, who also modified their device serial, reported that a full restore seemed to work okay. Maybe it’s just me. Who knows!
My point there is that this is all extremely undocumented, and we have to work with the knowledge we have to hand!
So, without further ado, let’s take a look. I’ll upload alongside this article the C representation I have created to automate the process of booting the ‘special image’ which allows us to make these modifications. The program is very simple, and calls external binaries which are installed alongside libimobiledevice.
I can’t provide said special image, but somebody on Twitter probably can!
In the code we can observe the device being sent into Pwned DFU Mode. This particular element of the process I reccomend running outside of an automated set of instructions like these. The reason for this is it ipwndfu often fails and we need to re-run it a few times.
There’s no error checking going on here, and the program would continue executing which isn’t ideal. TDLR, execute ‘./ipwndfu -p’ before running the script!
Now, following this code executing, our iPhone should look something like this…
And what does this mean for me?
It means you can now connect via physical serial! (i’ll explain virtual serial afterwards, best to get this out the way first so we can understand how serial works!). Just for clarity, Serial is the communications channel we will be using to interface with out device. Let’s begin by listing out ‘Serial Ports’ connected to our mac. The DCSD Cable is one of them!
Use the command ‘ls -l /dev/cu.*’ will list connected USB Serial devices. Take note of the contents following the ‘-’ in the result.
Now, let’s connect to our serial port!
To do this, we need the address of the serial port ( we just figured that one out using the command we executed! ), and finally, the baud rate. The baud rate determines the ‘speed’ of data transfer. I have created a little diagram explaining the general concept of serial and i’ll paste it below for you!
The command you’ll need to start interfacing with the iPhone via the serial port is 115200. We’ll paste the following commands into our terminal session to connect, replacing the serial with the value we retrieved earlier:
‘screen /dev/cu.usbserial-SERIALHERE 115200 -l’
If you’re lucky, you’ll now see a blank screen! This might sound a little counter-intuitive. But it means we succesfully initialised the connection. Hit enter on the keyboard, and you should be presented with a prompt. This is where we’ll enter our commands for the serial number modification.
be. careful. Please!
We can now begin entering our commands, such as ‘sn’ which will print out your current serial number.
We can use the syntax ‘sn SERIAL’ to re-write the embedded serial number, stored in SYSCFG. Again, do keep in mind these changes are permanent (unless manually reverted using this same procedure).
I still don’t have a serial adapter. Where’s the virtual guide?
User @matteyeux on Twitter has kindly made the public aware that you can enable a ‘virtual’ serial adapter in order to communicate with the special software!
We need to back track to the script at the beginning of the article in order to implement this, and should be an easy fix!
Alternatively, it also appears we can set the boot argument from normal mode, executing
nvram boot-args=”usbserial enabled”
over SSH and then using our normal boot method.
Our newly implemented virtual serial code looks just like this, and following the execution of this code in comparison to the first edition, is that we should now be able to see the ‘Virtual Serial Adapter’ when we execute ‘ls -l /dev/cu.*’. Then all we have to do is use that value when initialising the serial connection over a normal lightning cable… and, BAM, we’re in!
That article was a little long-winded I guess, a lot of information in a short space. I will almost-definitely update this article to ensure it's a little easier for beginners to understand.