Just a few more thoughts. There is an old key and a new key: the old key was obtained using the “encryption oracle,” and it allows you to decrypt the whole firmware. This key was shared with the old OP-1 firmware and was later changed for a new one.
My guesses are:
The old key itself should be embedded in the decrypted firmware, which allows us to search for its location and identify some prefixes and suffixes around it.
Thus, we can still decrypt the latest firmware encrypted with the old key, and this time the decrypted data should contain the new key, allowing further updates with it.
Using knowledge of the position of the old key (prefixes and suffixes around its location) in the firmware (any old firmware encrypted with the old key but the last) could help identify the new one in this decrypted firmware (last firmware encrypted with the old key).
I already posted this over on Reddit, but over the past two days I’ve been hacking scale quantization into the original OP1 firmware using some of the tools that are described way up at the start of this thread.
It was surprisingly complicated. I’ve never done decompilation before and I worked with Codex on it. It was quite an adventure. One cool thing that I figured out as part of this is that I could log information out of the OP1 by editing bytes in one of the audio samples that I could mount as a disk. That helped a lot.
Anyway, I’m really excited about this for myself. It’s a feature I’ve wanted for a really long time, and I’ve noticed that people have generally asked about this feature before, so hopefully more people out there can enjoy as well. Obviously proceed at your own risk. This involves patching firmware in an unsupported and warranty-voiding way.
I’m very curious if you all figure out how to crack the xy or the 1f. If you do, I would definitely be interested in bringing this kind of feature to those as well.
I was writing an entirely other question, but I realized-- I want to know how the key detection and transposition work and I’ve spent several weeks shaving this yak. My screen name is also my email address at fastmail, so if someone who knows @_bt 's work is willing to talk, my inbox is open (or my DMs on here). I of course won’t ask what the sender’s screen name on here is.
My original question was whether the filename region is decrypted and its last block is fed as the IV into in the decryption of the encrypted payload or whether the original IV from the zfw file is used.
I’m not sure if I understand your question, but the encrypted filename region is its own encrypted block (0x300-0x400). The actual firmware zip is also its own (Offset 0x400 to the end of file). The IV is used for both.
The idea I had was to create new “firmware files,” starting with the first AES block in the firmware zip region and place it into the encrypted filename region. Load it into the OP-Z and read the serial console as I attempted the firmware upgrade. The encryption oracle decrypts that first “firmware file block” and puts it into plain text into the serial console.
Record the decrypted plaintext block into a new file. This “firmware upgrade” will fail because it’s not valid. Build a “new firmware” using the next ciphertext block in the “firmware file region” and reset the OP-Z. This next block is where it gets a little more interesting due to the CBC-mode used with AES. After you decrypt after the first block, you must XOR the next block with the previous ciphertext block, and then XOR again with the IV.
Assuming Pn is the n th plaintext block, Cn is the n th ciphertext block, IV is the initialization vector, ⊕ is the XOR operation, and O() is the encryption oracle, it follows this pattern:
P1 = O(C1) P2 = O(C2) ⊕ C1 ⊕ IV P3 = O(C3) ⊕ C2 ⊕ IV P4 = O(C4) ⊕ C3 ⊕ IV
… Pn = O(Cn) ⊕ Cn-1 ⊕ IV
This is not a fast process and takes a long time to do due to how long it takes to power cycle the OP-Z. Maybe someone else can find a faster way to do it other than what I used though.
Note that these offsets and ranges are all based on the OP-Z firmware file format, but as far as I can tell, the new products all use this file format, with the addition of a new header (0x00-0x7F) prepended. I’ve got the file format partially mapped out on the GitHub repo. There may be errors though.
I have no clue if there is a similar encryption oracle vulnerability in the OP-1f.
What I’m specifically asking is whether (and forgive me for formatting and abuse of notation, I haven’t quite figured out how you typeset the equations, so you’ll have to render them in your heart) the block at 0x400 is decoded as
$P_{0x400} = O(C_{0x400}) ⊕ IV_{0x70}$
(where IV_{0x70} is my poor abused notation for the IV located at 0x70).
This is actually the last detail I need to figure out, though interestingly, when I modified the last byte of the IV, it didn’t actually harm the booting, which is odd. My more concrete question is whether anyone would hypothetically be willing to send me the a 256 bit sequence, which for legal reasons I cannot say is an AES key and for legal reasons would likely make us unwelcome on this forum and therefore should likely be sent over other channels
