Hi, did you look into this any more? I just updated the field firmware archive so it now has every official firmware update. Out of curiosity I binwalked all of them but the results for each file is very different and inconsistent, so I suspect the binwalk results are probably all false positives. I suspect the files are somehow encrypted or compressed. I don’t have a OP-1f and not looking at getting one so for now I’m not going to spend time investigating this further. I’d be glad to poke around if there’s any way to unpack any of it.
Hi, yes I have looked into this more. It appears the OP-1f firmwares are very similar to the OP-Z firmwares, but the op1f firmwares have a binary blob at the beginning of the files from 0x00 to 0x7f. These files are mostly encrypted, and I’ve documented some of the OP-Z firmware file formats here: Firmware · billymeter/rez Wiki · GitHub.
It’s interesting to note that if you look at the byte at position 0x84 in firmware 1.1.4, and that position in the later versions, changed. I believe this is a “key index” which presumably determines which key the device should use for decrypting the firmware. It looks like they changed which AES key they use to encrypt the firmwares starting with version 1.1.6. Prior to that, they used the same key as the OP-Z firmwares.
Feel free to PM me if you want more details on how I know this.
Hi! The only functionality I really miss in my OP-1 is the USB host function. Would it be possible to add it through hacking the firmware or it’s impossible due to hardware limitations?
yes, but no.
The hardware is probably capable of that. At least the BlackFin CPU used in the OP-1 does mention USB OTG Host in the description. Not sure the variant in the OP-1 really does.
Not that important though because of the work needed to actually modify the firmware.
As mentioned in the long thread here several times, nobody took the time so far to fully reverse engineer the FW to a point where any part is really understood, modified, re-packed and uploaded so that the rest of the FW still works as designed and the new feature is in.
And that is true for even the smalles of mods (e.g. allowing more drumkits). Adding a working USB OTG Host with all the code and handling needed for that?
I don’t see how anyone capable of doing that would invest the time.
Hi 3sleeves Im new here but I spent this whole week reading the chat log and I love what you are doing that tape screen setup is incredible honestly it’s what I wished TE would have done for a functional UI. I need to give praise to everybody’s contributions here Tabasco, Wavi, eesn and everyone else your work and efforts are so appreciated.
I would really like to work on some the SVG aspects of this project please get back to me and if you could send me those SVG’s you created id like to look at what we have confirmed works. much love Happy holidays and wishing all a happy new year
I stumbled across this interview with the TE guys and this may be interesting for this group, especially from minute 27 about the AGG graphics:
Very interesting topic. I’ve only grazed through it since it’s so long but impressive.
Since you guys were able to get in deep at the OS level for the OP-1, does anyone have any idea how to use this info to make a synth patch importer for the OP-Z?
The one thing no one can do is export synth patches from the OP-1 or another OP-Z and import them to another one. Only regular samples work via copying them over to the mounted drive.
The synth engine patches have been elusive as you can see with some existing threads in this forum. Sadly the iOS OP-Z app doesn’t help with this. Any ideas would be welcome sicne I want to use more than new samples - need new synth patches. Thanks…
I know it’s long and a lot of content, but this has all been discussed in this thread already.
OP-Z and OP-1f seem to have encrypted (and signed?) Firmwares. So TE doesn’t want us to poke around anymore, I guess.
One would have to somehow crack or leak the key(s) to get anywhere with that.
ususally that involves Hardware attacks like voltage glitching and such, which would require one or more units to be dismantled and possibly fried in the process.
So I highly doubt this will happen when a unit costs 600-2000€
Didn’t @_bt mention something about this though? At least their comment hints at deeper knowledge about the firmware encryption.
I’ve been meaning to post an update to this. How I know that they changed keys with OP-1f firmware version 1.1.6 is that I have the key they use in the OP-Z firmwares and the first few firmwares of the OP-1f.
There’s actually a crypto vulnerability in the OP-Z which enabled me to get the encryption key. The gist of it is, refer to the documentation I’ve written on the OP-Z firmware here. There is a section of the firmware binary blob which contains the encrypted filename. This can be manipulated since the OP-Z firmware is not digitally signed.
The OP-Z also exposes a serial interface when the USB port is connected to the computer. When attempting a firmware upgrade, while observing the serial console, a status message is displayed saying it found a firmware file
firmware_bin_only_with_bootloader.zip, which was decrypted from the encrypted filename portion of the firmware.
Using these two facts, I rigged up a solution to power cycle the OP-Z, and a script to dynamically create brand new firmware files to decrypt the firmware payload, block by block, by replacing the encrypted firmware blocks with the actual firmware blocks, and initiating the firmware upgrade procedure while noting was was decrypted in the serial console. The OP-Z will happily decrypt these blocks, but is smart enough to know it’s not a valid firmware file, and aborts the upgrade process so the OP-Z is not bricked.
This took a very long time to do (around 30 seconds per block in some cases, and there were thousands of blocks), but it was finally done with some assistance from @tolsi. After getting the decrypted firmware zip file, I wrote another script to take the contents of the bootloader file an attempt to use that as the decryption key on the encrypted firmware. The key is in plaintext in the bootloader file.
I have been able to repack OP-Z firmwares into “custom ones,” but this is only a technicality. I’ve made no improvements or new features to the firmware, and merely just updated the version number in my proof of concept. The status of this is basically at the same point as @TabascoEye’s work on the OP-1 firmware: we still have to be able to reverse engineer the firmware itself for it to do anything meaningful other than cosmetic changes.
When the OP-1f was announced, and firmware for it was made public, I downloaded a copy to see if they happened to use the same encryption key, as the OP-1f firmware files have a very similar file structure to the OP-Z firmwares, and sure enough, the same key was used. The key was changed in OP-1f version 1.1.6 for some reason (someone from TE saw this thread?) but I’ve basically stopped working on it at this point.
“Cosmetic changes” as in unbending the case?
Seriously, as a noob I find all this fw hacking business really fascinating… When I look at youtube it seems there was a real push for these reverse engineering topics in the last years with Ghidra and such, wouldn’t that make things easier than back in the days?
I wouldn’t say “easier” but certainly more accessible compared to back in the day when you needed to invest in Ida Pro. Obscure architectures (i.e. not x86 or arm) are still a “problem” though.
Btw, I watched your talk on YT from 7 years ago, that led me down a rabbit hole and I ended up watching 4 hrs of 37C3 videos about voltage glitching tesla autopilot, etc now i feel like a total hacker and will totally put the latest custom fw on my op1
playing around with a repacked 246 right now - what’s the deal with com.svg? it shows the OP-Z track symbols on top and OP-Z in yellow font. Did I miss some updated functionality here?
Could anyone change the drummer to an octopus?
now we’re talking
it could be you!