After the decryption process completes, the decrypted data is downloaded. The process of decrypting is taking part on the iPod itself, so you must have a compatible device in order to use the utility. Also, you must run the iBugger utility on the device before using ipodcrypt. In order to run these utilities, you will need the Python interpreter installed, the pyUSB module and libusb. It is possible to run the utilities on both Windows and Linux.
It uses libusb-win32 1. Its download page is: You can get it from the download page or another mirror. The 0. Otherwise the driver will install after confirmation that it is unsigned , but it will not load unless you disable driver signature check, which is not recommended.
To use the 1. Alternatively, you could right-click the checkra1n. Otherwise, with Linux you can install the latest via the repository then launching the checkra1n CLI:. The process will begin with checkra1n running the device exploitation stages until a device boot is initiated. The Apple logo will show following the checkra1n logo shortly after along with some text on the screen.
From here the user can execute the pongoterm command to enter the PongoOS shell. Inside this shell you can type in sep auto which will start the Secure Enclave Processor exploitation process. From The iPhone Wiki. Jump to: navigation , search. For more history, see Firmware Keys.
Category : Decryption. Navigation menu Personal tools Log in. Namespaces Page Discussion. Views Read View source View history. Miscellaneous Ground rules Timeline. This page was last edited on 13 March , at But it still doubles in some places after the first 15 bytes: The bytes double, same with and it does so at many more places throughout the file.
Instead of showing the values of the individual bytes, we could show the amount the next byte deviates from the previous one. One could use subtraction, but in the case of bitwise operations, XOR makes more sense. These are the counts of the most common by a wide margin values.
One then has to consider that this is not the result of a single keystream, but of a XORed version of two keystreams. So we have 4 possibilities for a byte of the keystream if we know the previous byte. There are 7 different firmware files from which we can infer possible values of the keystream.
This is done by XORing a pair of files and looking for long sequences just consisting of the those 7 XORed deviations. This also lets us infer the values for A6 and AA at that location. These appear to have the exact same keystream, since aforementioned values pop up nowhere and instead abnormally many 0s not as a XORed deviation, but in the values themselves show up. One thing this allows is applying the constraints from the keystream of either A4 or A4b to both at the same time, allowing us to derive more of the keystream.
But with that, we only know the XOR of one byte of the keystream to the shifted version of the previous one. However, after eight bytes of knowing the exact XORed deviations, the unknown part gets completely shifted out and we know the exact values of the keystream, up to a constant XORed value.
Writing a program that does automatically solves the constraints on longer sequences of the 7 XORed deviations, one already obtains plaintext bytes in A4 and A4b combined without any manual decoding.
Towards the end of this decoded version, one will find many repetitions of the bytes 0x7E. This is likely padding and is often 0, meaning the constant XOR value is probably 0x7E. Indeed, looking at the bytes themselves, they do look like code. The 80 and 81 pop up because it the firmware seems to store values in XRAM around 0x Knowing that the plaintext will be firmware, one can then make an application where one can set the values of the keystream and see the corresponding disassembly for the plaintext of A4 and A4b.
With 2 plaintexts at once, one can then mostly find out which keystream to choose. For some orientation, the first column is the automatically inferred bitmask of possible XORed deviations. The second one is the user-defined override, then two columns of ciphertext A4, A4b. The 3-wide column after that shows the number of possibilities the keystream can have at that place in hexadecimal.
After that, two pairs of hypothetical plaintext, including disassembly. I love repetitive work, so I decrypted the whole file within a night, without realizing the time that had gone by. After that, it would be possible to reverse engineer the firmware itself to modify it and then find out the decryption algorithm. However, I kind of wanted to see if one could reverse engineer the cipher from the files themselves or at least a cipher which happens to decrypt all existing revisions.
Next is to find out how the XORed deviations are chosen. Stream ciphers are often based on LFSRs linear feedback shift registers made non-linear by some function. Indeed, the way this keystream is formed kind of looks kind of like a Galois LFSR, which works by XORing the n bits with a constant value if the shifted-out bit is one. However, in this case, it is not a constant value, which makes it non-linear but still comically weak because of the use of the whole lower byte, instead of one bit, per state.
0コメント