Cobra blackfin reverse enginnering part 2

Nous apprenions en septembre, par l'intermédiaire de WOLOLO qu'un mystérieux développeur menacé la team cobra de dévoiler tout le travail qu'il avait effectué pour eux sur le développement du Cobra Blackfin, il avait alors expliqué n'avait jamais été payer pour le travail effectué alors qu'il était sous contrat avec la team et que le travail avait démarrer en 2013 pour se finir en 2016.

Il avait donc délivré une partie du travail en guise de preuve et avait était critiqué notamment par yfanlu et d'autres alors que tout travail peut faire évoluer la scène.

Cette solution pour la Vita beaucoup critiquée a donc été critiquer pour son aspect commercial et creer des tensions dans la scène.

Aujourd’hui il récidive en livrant une autre partie de son travail et pas des moindre, le code de toute la partie software du Cobra Blackfin!

Il remet à sa place dans l'article Yfanlu en montrant le travail colossal qu'il a du effectué.

Ces explications et son code pourrait permettre d'apprendre encore d'avantage sur votre console préférer et faire avancer la scène.

Traduction française(en cours) des dires du dev:

Quote

Ma seconde release. Plus importante que la précèdente, la partie Software du BlackFin elle-même (avec quelques infos sur le doncgle BlueTooth), cela peut être utile pour pleins de choses que  le contrôle hardware du  BlackFin . Vous avez une librairie de communication GObject Serial , une implémentation Bluetooth pour puce TI , un API wrapper pour libftdi/libftdxx, un patch pour ajouter a libexfat le support pour le système de fichier GC, un tas d'informations sur le système de fichiers utilisé et le protocole de communication. Simplement 33k lignes de code au total, et je suis sur qu'il va falloir beaucoup de temps à la communauté pour examiné et extraire les parties intéressantes pour eux.

Le code a démarrer en 2013 et finalisé en 2016, j'ai toujours voulu qu'il soit sous licence  GPL, mais je n'en ai pas eu la permission à la dernière minute. Il y a déjà un  README qui contient un lot d'explications sur les fichiers , le design, les protocoles et les sytèmes de fichiers, mais ceui-ci est un peu dépassé.
Regaerder les notes du code pour plus de détails et une mise a jour du readme data.
Les fichiers de g-serial sont licensés sous MIT license comme ils sont un portage d'un projet  GObject existant sous licence MIT. Les fichiers libexfat files conserve leur licence et  copyright, et un patch  contre upstream en cas de  review. Tout ce qui concerne, une partie de DirectC, est considéré sous licence GPL.Je vais utiliser cette annonce pour dire quelque chose à  Yifanlu qui a été vraiment agressif envers moi, ravi et  content sur le fait qu'on ne m'ait pas payé pour mon travail. Dénigrer quelqu'un pour s'amuser est ridicule, tu pense que motoharu a été plus loin qu'un contrat "pirate" en 4 ans et tu dit que  ca n'est pas comparable a un vrai travail” [1] alors que tu n'as même pas regarde les fichiers releasés, c'est pathétique. Ce que motoharu a fait est impréssionnant, c'est un gros travail et sur certain aspect il a même été plus loin que moi, mais  4 ans après moi et par un chemin totalement différent. Il a  reversé le protocole d'authentication avec le reverse enginneering du kernel/ASM alors que moi j'ai utilisé la Vita comme une boite noire et reversé en analysant l'échange des données, utilisé un analyseur logique et bruteforcer les  commandes et arguments. Comme il a achevé plus de travail que moi , j'ai  achevé plus de travail que lui mais sur différents chemins. 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”[2] 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.

[1] https://twitter.com/yifanlu/status/907821018894307328
[2] https://twitter.com/yifanlu/status/908040705200635904

 

Quote

Explications en anglais pour la compilation:

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

La release est disponible ici: http://wololo.net/downloads/index.php/download/10236