About a month ago I was contacted by a person who states they are the main tech person behind the Cobra blackfin device (and have pretty much confirmed it by now, given what they have released). I have agreed to publish this person’s work and announcements, unaltered. You can see details of this agreement, as well as the first release, in the original article.
This second part of the leak was send to me a few weeks ago already but I delayed this article for no good reason.
Today’s release contains the actual Blackfin software. Following on my commitment, below is the developer’s announcement and their notes. I haven not modified anything except for potential formatting to fit the blog’s design/constraints.
My second release. This is a much bigger one, and while it’s the BlackFin software itself (with some info on the BT dongle), it will be very useful for many things other than controlling BlackFin hardware. You get a GObject Serial communication library, a Bluetooth implementation for the TI chips, a simple API wrapper for libftdi/libftdxx, a patch to libexfat to add support for GC filesystem, a lot of information on the filesystem used and communication protocol. This is simply massive with about 33k lines of code total, and I’m sure it will take some time for the community to go through it and extract all the things it can find useful in it.
The code was started in 2013 and finished in 2016, I always meant for it to be released as GPL, but was prevented from doing so at the last minute. It already had a README file which has a lot of explanations on the files, design, protocols and filesystems, but those might be slightly out of date. See the notes for more details on the code release and an update to the existing readme data. The g-serial files are released under MIT license as they are the GObject port of an existing MIT-licensed project. The libexfat files retain their license and copyright, and a patch against upstream is provided for review. Everything else, apart from DirectC, is to be considered GPL licensed.
I’ll use this announcement to say something to Yifanlu who was very vocal against me, delighting in joyful bitterness and enjoying the fact that I was not paid for my work. Bashing someone for the simple joy of bashing them is ridiculous, you think that motoharu got further than “a pirate contract in 4 years” and you say “real skill doesn’t compare”  when you so clearly haven’t even read the released files is pathetic. What motoharu has done is amazing, it is a lot of work and in some aspects he achieved more than I did, but he also achieved it 4 years after me, and in a completely different way. He reversed the authentication protocol through kernel/ASM reverse engineering while I used the Vita as a black box and reverse engineered it through analysis of exchanged data, logic analyzers and brute forcing commands and arguments. Just like he achieved more than I did, I have also achieved more than he did, but both did it in a different way. I think we both complete each other’s work and I am happy to see what he has done and I am happy to share my findings with him to help complete the bigger picture. I am a human being, just like you, I need to pay my bills and survive in this world, just like everyone else. I work on a contract, and (usually) get paid for it. I’m not responsible for what people do with the code, just like you’re not responsible for people using Henkaku (your work) to pirate games, so drop down from your high horse and don’t use your “on the internet? LUL” argument for being a bully. The internet does not justify being rude to people. The BlackFin device does have legitimate uses, and whether or not it was promoted or even sold as a piracy device, it is irrelevant to me. I was simply happy to be provided high end hardware and be financed to crack the mystery of the Vita. I’ve been had by an untrustworthy person, and that is not cause for celebration. Especially if you hate Cobra and piracy-enabling devices, why are you celebrating that the only person benefiting from the situation is the owner of the Cobra business? Haven’t you done the same thing by the way ? You just crowd-funded your efforts instead, and now you’re selling a device which you know and can’t deny is being used by people to enable them to pirate more easily. Let me be sarcastic and just point out how non-hypocritical you are.
Here is a story for you. I had reversed most of the GC protocol and authentication even before the US release of the Vita. I have here a video timestamped May 8th 2012, showing me running a full game being streamed entirely from my PC through an FPGA emulating the Vita GC protocol and proxying commands/receiving data over a serial connection with the PC. That proof of concept is beyond what was achieved by anyone else at that time, and maybe even today, and it would not have been possible without the proper hardware and financial backing necessary. The four years that followed were what was necessary to go from that proof of concept to an actual working product. Have you ever actually seen a BlackFin device? I may be *** at Cobra, but I am still amazed at what we have achieved. The BlackFin GCEmu (Game Card Emulator) is such a ridiculously small device. It’s a 15x15mm PCB, of 0.4mm thickness, which packs an FPGA, a Bluetooth module microcontroller, a security microprocessor, an antenna, and battery (in the form of capacitors, able to keep the device running for over a second). The miniaturization efforts were enormous, getting the FPGA code to actually fit in such a small FPGA footprint was a challenge, having to rewrite the code in order to decrase the bitstream to less than 10% its original size when it was running on a full-sized FPGA. Getting the Bluetooth to work even though the Vita card holder is shielded was a challenge, keeping the device powered while the Vita shuts off the power to the device was a challenge. We actually wasted one year in testing out numerous batteries, various ultra slim (100 micron) thick batteries, and testing various components for power consumption, because the Vita will shut down the power to the device if you don’t authenticate after 2 seconds and it’s not enough time for a user to choose which game they want to play.. we eventually had to fall back on using capacitors that are capable of holding the device powered for over a second, just enough to keep the INS line asserted long enough for the Vita to timeout on the ‘card ejected’ signal and allow us to ground the INS line again once power runs out of the capacitors and the Vita picks up on the new ‘card inserted’ event, allowing us to keep the card powered for an indefinite amount of time, with 1 second lapses every 15 seconds during which the device goes into low power mode, asserting INS and the vita thinks the card was ejected and reinserted. We also had to include a microSD inside of such a device, have both an MMC client implementation, and an SD card host controller, as well as Bluetooth communications and encryption support to fit within a 3x3mm footprint FPGA. Of course, we also had to discover micro injection molding in order to make the plastic casing for the device with under 0.1mm thicknesses in some areas, with baffling accuracy and error margins (which forces the use of ultrasonic wielding since we can’t glue the pieces together). We couldn’t even put a sticker with the logo on the cards because it would make it too thick, so the card had to have the logo printed on the plastic instead. Now that’s just a quick GCEmu summary of challenges, I’m not even talking about the challenges for the GCReader, on getting a custom made card slot designed for us, or the hardware challenge in getting the GCReader to detect when a GCEmu is inserted in it without allowing a Vita to discover that the inserted card was a GCEmu, or the software challenges of writing the Bluetooth embeded firmware, how to improve throughput and exchange data between the device and the PC using Bluetooth Low Energy, which was never meant for high throughput data exchanges. Also, do you realize that we had to define a good and usable filesystem for the games and implement the filesystem support in the FPGA while making sure it takes a minimum amount of gates and doesn’t impede on the performance either ? Obviously an NTFS or FAT32 implementation alone would have busted our gates threshold in the FPGA. The entire story of the BlackFin would be too long to tell, at least for today, but I think that your saying “real skill doesn’t compare” when you didn’t even read the notes of the release (which clearly stated that information was from 2012 and was a first of many releases, and you thought it was the culmination of 4 years of work) is showing a poor character on your part. You judge and try to deliberately humiliate and make fun of other people’s misfortunes. I had respect for your skills before, but today I am sorry to realize the kind of person you are, behind those skills.
I will also take this opportunity to say something to wololo as well as others like him, who, while being against piracy, have not let that taint their opinions, and have shown empathy for my situation. You didn’t have to but it is appreciated and it shows your good nature, so thank you.
My final announcement is for everyone who is hoping that these releases will somehow unlock 3.61+ firmwares. I do not think that to be the case, however, with the work of motoharu and others in the community, the entire authentication algorithm could soon be reverse engineered and game backups running on the latest firmware should be possible. This release would cut down a huge amount of time in setting up the foundation for the software controlling a potential open source device that would work similarly to the BlackFin device but without the P2P aspect of it.
This is the entire BlackFin software. You must build it on Linux. I don’t think I ever managed to properly build it on Windows, even with mingw, but you can cross compile it with mingw on Linux. Note that libftdi (open source library) works great under Linux but very poorly in Windows, while the libftd2xx (official proprietary library) works great on Windows but crashes constantly in Linux. That’s why the program can be compiled either against libftdi or libftd2xx, and if you’re running linux, it’s best to have libftdi installed so it gets picked instead of building against the static libft2xx library.
Before I dig deeper into the Blackfin software, I’ll talk about the BT Dongle. When Blackfin was released, it came with a dongle, and I saw a lot of angry posts about “death to the DRM dongles”. I found that to be very funny because the BT dongle that came with the BlackFin was actually NOT a DRM dongle, it was nothing more than a Bluetooth Dongle. Due to having to use BTLE (Bluetooth Low Energy) which was not yet very popular, at least, back then, we had to release a USB dongle for people to have BTLE capabilities. The dongle is the exact same as the TI CC2540 USB Evaluation Module Kit that is being sold for 49$ USD by TI: http://www.ti.com/tool/CC2540EMK-USB#Technical Documents You can find the schematics, BOM, CAD, PCB, and gerber files for the Dongle here : http://www.ti.com/tool/TIDC-CC2540-BLE-USB The only difference between those files and the actual BT Dongle sold with the Blackfin is that the PCB was made slightly larger in order to fit into an existing plastic molding that Cobra had, and the programming header is not soldered. As for the firmware running on those dongles, it’s the standard firmware that comes with the TI USB module kit, of which you can download the sources if you download the TI BT SDK for the dongle. I believe the firmware was a sample called ‘HostTestRelease’ in the SDK. I’ve attached the full TI BLE Vendor Specific HCI Guide which lists all of the commands and specifications of the BTLE Dongle. The dongle is not encrypted in any way, and you can re-program it with your own firmwares if you wish to. You would need a TI programmer though and to solder a header on the PCB to connect the programmer to it.
There are a few subdirs which I’ll explain first : * libexfat: This is the libexfat subdir from exfat : https://github.com/relan/exfat/tree/master/libexfat More precisely, it’s an old checkout that I never bothered to update, it is based on commit d1370b2cc7cc986b712e1a27a49b23a9eadb3cec from April 3rd 2012 (https://github.com/relan/exfat/commit/d1370b2cc7cc986b712e1a27a49b23a9eadb3cec). All modifications have been extracted and explained in the libexfat_blackfin.patch file that I placed in that subdir. The patch does not need to be applied, it’s just a diff between that commit tree and the directory here. The patch can be reviewed for what exactly was changed in the library. It does a few things : * Makes use of Glib’s macros if USE_GLIB is defined (which it is) * Fix/Port it to get compiled for Windows with mingw * If CUSTOM_IO_API_PREFIX is defined, will replace all I/O API calls (open/read/close/seek/etc..) with a custom API for use within a GC iso partition This is used to replace all I/O calls with gc_fs_ex_io_*, see LIBEXFAT_CFLAGS in the Makefile.am * Don’t abort() the program if an exfat error is encountered * Fix printf format to be cross platform * Add support for TexFAT (read-only) which has 2 FAT tables instead of 1 as all GC images are in TexFAT format
* flasher: This was a standalone flasher app to flash the GCReader with updated firmwares. It’s still here but its code was merged into the main application itself (see gc_reader_flash_firmware API in gcreader.c). * directc: This is the DirectC library by MicroSemi, it implements the FPGA flashing protocol. The only modified files are dpuser.h and dpuser.c which make use of the FTDI to send the JTAG commands * libft2dxx: Binary library for compiling against libftd2xx * drivers: Simple rules.d file to allow access to tty devices for everyone. BlackFin reader is an FTDI which is a tty device, and without it, you need to sudo to be able to access the reader. This is for linux only. The windows drivers are in the official release. * firmware: This to be the latest GCReader FPGA firmware, it’s encrypted of course. I don’t think I have the key for it.
As for the code itself, it should be fairly easy to understand. It’s already explained in README but since that might be outdated, I’m re-doing it now. Here are some explanations for the weird files : * DS – Dispatch Server, that’s the actual server that links two clients (emu and reader clients) together. The file was left as its old filename of ‘DS’ but the Makefile compiles this into a BlackFinServer executable * EX – Exfat I suppose? this reads an iso, goes through directories and files to find the SFO and extract the game ID, title and file offset which holds the license file. **Not compiled by the makefile** * FS – File system utility: Tool to print, format, add, delete isos from a microSD card. It’s hardcoded to use /dev/mmcblk0 so it needs to run as root and it needs to run on a machine with an SD card reader that maps to /dev/mmcblkX (USB card reader will sometimes map to /dev/sdX) **Not compiled by the makefile** * OAD – TI’s OAD implementation. This will communicate with the GCEmu over bluetooth and perform Over-The-Air Firmware upgrade using the custom data exchange protocol defined in the GCEmu firmware. It also supports sending an FPGA update for getting the BTLE MCU perform JTAG firmware update of the GCEmu FPGA. Read the code to understand what it does, as I don’t remember the specifics. Also read this http://processors.wiki.ti.com/index.php/OAD * build_win32.sh: script I used to build for windows with mingw
Here are the less weird files that are part of the software : * blackfin.c: Main application, creates the UI and the reader monitoring routine, creates new reader tabs when they are discovered * btcomm.c/h: Bluetooth communications framework. It talks to the USB BTLE dongle using the TI vendor commands and the API can be used to do most of the basic commands and send notifications about the BT status, it has no blackfin related code, so can be reused anyw ay you want. * card_cache.c/h: Just writes/reads a cache file which stores a mapping between a card’s serial number and the game id/title/license so cards can be shared without being authenticated every time the app is launched, authenticate a card once and the data is cached via this API * client.c/h: Base class for protocol client. It does the basic connection establishment and teardown (see gcemu_client and gcreader_client for subclasses) * common.c/h: common GUI related utilities * fakeserver.c/h: Implements a fake client/server implementation to allow the rest of the code to do the card authentication locally without the need to handle the case separately and without going through a server * filesystem.c/h: This implements the microSD filesystem. This is the API used by the FS utility and the filesystem format itself is explained in the filesystem.txt file as well as the README file (both might be outdated, source code remains the best source of accurate information) * fsio.c/h: The FSIO is an abstraction for Filesystem I/O operations. The fsio.c implements the fs_io_file API which is to access local files. The other FsIo implementation is in the gcreader.c file to implement read/write into a card on a GCReader. This allows to do things such as dumping a card into a file, or adding a file to GCEmu or adding a card from the reader directly to GCEmu, etc.. using the same FsIo API. * ftdi_util.c/h: Abstraction API for accessing the FTDI chip using either libftdi or libftd2xx * gcemu.c/h: GCEmu implementation. This is what uses the btcomm API to represent a GCEmu card * gcemu_client.c/h: The client implementation to represent a GCEmu over the network to the Blackfin server * gcemu_tab.c/h: The GUI implementation to represent a GCEmu object on the UI * gcfs.c/h: The Game Card FileSystem. It just uses libexfat to read a game iso, list files, find the id/title, license file, etc… * gcreader.c/h: GCReader implementation. This is what uses the ftdi API to communicate with the GCReader hardware * gcreader_client.c/h: The client implementation to represent a GCReader over the network to the Blackfin server * gcreader_tab.c/h: The GUI implementation to represent a GCReader object on the UI * g-serial.c/h: A rewrite of William Woodall’s serial library into a GObject. Released here under the same MIT license. https://github.com/wjwwood/serial The port was done in 2013, and was slithgly updated throughout the years, but it might be outdated from upstream at this point. * prefsdiag.c/h: Preferences dialog UI implementation * progressdiag.c/h: Progress bar dialog UI implementation * protocol.c/h: Protocol implementation for the server/client, this handles the low level protocol communication format and dispatches commands/responses to the actual implementors of the protocol * server.c/h: The implementation of the Blackfin server * settings.c/h: Settings class for get/set of various runtime configuration options * sfo.c/h: SFO parsing API, returns SFO data as a hash table * utils.c/h: CRC, hex_dump and time utilities