> Using that part number I wasn’t able to find any information about the chip online apart from an article that claimed it was based around a “SuperH” CPU core – an ISA that I’ve encountered for the first time ever in that article.
Also found in Sega 32x, Sega Saturn, and Sega Dreamcast! And some early Pocket PCs (turn-of-the-century handhelds running Windows CE) like the HP Jornada series, although most Pocket PCs were ARM-based.
You mention "another packing optimization". I'm wondering, how are you transferring frames? The dot matrix is eight 7x5 characters, i.e. 280 bits in total, which amounts to 40 7-bit groups per frame. You seem to be using twice that space in transmission, is it wasted on some control data or is the transmission just slightly suboptimal?
The dot matrix is actually eight 5x8 characters, or 320 bits in total. I'm packing those 320 bits into the the 4 bits per byte that are available to us in this shell protocol. Plus, another 9 bytes for the packet header and footer. Looks like I wrote 92 in the article, I must have miscalculated that.
I'm not using the full 7 bits because figuring out a way to do so turned out to be way too hard for me, so I opted for a solution that is negligibly worse than the optimal one, in comparison to the original one.
If you're wondering about the exact algorithm, consider checking these files out, but please keep in mind that I haven't cleaned the code up yet: https://github.com/portasynthinca3/swl01u/blob/master/fun/bi..., https://github.com/portasynthinca3/swl01u/blob/master/fun/ba...
Lol… where does that leave the rest of us in comparison
There's been MIDI shell code for well over 20 years on pretty much all major platforms: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=midi
So to test this, surely they tried it once, and presumably Metasploit users generated tons of them .
And from having worked in this space a long time ago, such CVEs would trigger a host of malicious midi files looking for holes, especially since people embedded them in webpages around early 2000s.
Around that time I'd routinely take a MS update, diff the DLLs, reverse interesting location changes, and craft shellcode attacks during training to show people how it's not very hard. And there were tons of people across the spectrum able to do similarly. CVE disclosures made them much easier to develop.
MIDI was more about unifying the entire studio of synths, samplers, drum machines, and recording equipment. And creating interoperability between various manufacturers of music equipment. It was a solution to the multiple control voltage standards that predated it and made it troublesome to tie equipment together.
Multi timbral synths (different sounds addressable per MIDI channel) were a later thing too, analog polysynths could play more than one voice, but very few could play more than maybe two different _sounds_ at once.
There is no reason you can't take a sequence of notes and do something else - pop up a root window for example. It isn't normally done because it would confuse everyone for no reason. (IIRC The original MIDI spec from the 1980s didn't have conventions of nearly as much and some midi devices did really weird things from note commands)
Cue Frankie Goes to Hollywood's "Relax" triggering Derek Zoolander to kill the Malaysian leader during fashion week
so we have jailbroken the Chrome using MIDI protocol to install extension that blocks adsof course webmidi must support sysEx, it's essential to work with midi2 at all. but mostly because you must parse the weird sized packet to properly ignore it.
what might show up are chrome specific sysEx messages which then leads to exploits as the article.
I'm sure I'd more code than what's in my 8yo repo, but the premise is simply https://github.com/prashnts/midipacks/blob/master/midipacks/...
Though Behringer is still quite good with it. E.g. their Deepmind can be pretty much 100% programmed with it, on top of already good MIDI CC scope.
I really like this comparison!
[0] https://www.usenix.org/conference/usenixsecurity17/technical...
> So yeah, these [keyboard manufacturer] madlads made a shell that runs on top of MIDI SysEx messages on top of USB.
> [T]he most interesting commands that we have are arbitrary memory read/write commands. So, if we really wanted to, we could just peek and poke the memory of the synth via MIDI.
> If we wanted to, we could write these messages to a MIDI file and play it on the synth like any other MIDI file. Hey, that gives me an idea.....
> From the countless sleepless nights of digging around in the firmware I’ve discovered a function that sends arbitrary data to the LCD controller.
In a way, this is a peek at the nightmare of Internet of Things (IoT, where the S stands for Security.) Almost any device might have a backdoor in it, and it might even be a stupid backdoor, like #0000.
I'm imagining dubstep would be the result
This sounds easy but with SysEx having no delivery guarantees, and no sense of connection/session it can be frustrating. Totally normal to get "packet loss".
There's an embedded YouTube video in the article as well, that appears twice. First at the top and then again further down.
https://www.youtube.com/watch?v=u6sukVMijBg
There are also several videos in the article that are hosted on the same site as the original article (so on the .ru site). Those are not included in the snapshot unfortunatelly. You'll see placeholders and the associated text that describes them but you can't view those via the snapshot.
It also contains a link to a GitHub repo at the end.
[0] you can test these by using https://www.cloudflare.com/ssl/encrypted-sni/
I will tell you how: derangement, a failure to engage with society and the degeneration/depravity of being one step away from making MIDI component improvised explosives and emailing your remaining friends a manifesto.
Ah just kidding, this is pretty sweet.
That's such a nice way to think about it. Maybe I should try giving RE a go again.