EurAsiayour console hacking resource
Select topic
  Create an account Home  ·  Your Account  ·  Online Shop  ·  Forums  ·  Downloads new  ·  Wiki  
Main Menu
· Home
· About Us
· Downloads
· Forums
· Info Pages
· Members List
· Online Shop
· PDA - AvantGo
· Private Messages
· Search Stories
· Statistics
· Stories Archive
· Submit Story
· Top 10
· Topics
· Upload
· Web Links
· Wiki
· Your Account

Online Shop
Credit Card


EurAsia Online Shop

new products
· R4i Gold 3DS RTS
· Mars Pro GM-816HD
· EurAsia File Collection 2017
· Matrix Infinity 2.0
· Sky3DS Plus
· Modbo 5.0
· Screwdriver GC/SNES
· X360ACE V3
· E3 NOR Flasher
· TX J-R Programmer v2
· Corona Postfix Adapter V2
· SuperCIC SNES kit
· SuperCIC cart key
· Gateway 3DS
· X360ACE V1
· Wasp Fusion
· 3k3y 3KR (SATA)
· Mtx Glitcher v1
· Xk3y Reloaded (XKR)
· 3k3y Ripper v2

complete price list

Tor Hidden Service
Tor Project
EurAsia Onion URL: wrqgfbrcgttkp6pi.onion

Who's Online
There are currently 386 guest(s) and 8 member(s) online.

dampro - Gradius - hungpt_85 - jarvisite - makuchan - mimun - modrobert - nextria

Welcome honored guest. You can register for free by clicking here.

Site Protection

Hot Wikis
PS4 firmware updates
3k3y nokeys ISO tutorial
3DS game fw updates
3k3y microSD recovery
PS3 SKU Models
PS3 Metldrpwn
Xk3y microSD recovery
Xbox360 motherboards
Xbox360 Reset Glitch Hack
PS3 Blu-ray Drive
Homemade Sputnik360
PS3 BD drive swap
PSP Crypto Keys
PS3 Hypervisor RE
PS3 Dongle User Guide
PSGroove tutorial
Xecuter LT Fakir
NSMB Modchip Tutorial
PS3 Glitch Hack

RSS Feed
News & Downloads & Wiki


Hosted By


Respected Sites
Home of the Hitmen
English Amiga Board
GXArena OFW Repo
Games and Consoles
Console Wizard
GameCube Linux
Xbox Linux
bunnie's blog


Pirate Party




Electronic Frontier Foundation
Amnesty International

Nectarine Radio

Demovibes Radio


Total Page Views
We received
page views since June 2002

Moderated by: Robert

EurAsia : Index Ľ Ľ PSVITA Ľ Ľ Cobra BlackFin project files partially leaked
New Topic   Post Reply
Author Cobra BlackFin project files partially leaked


Registered: 2003-10-17
From: Bangkok
Messages: 6240
Status: Online
 _#35660 posted 2017-09-13 @ 07:25 GMT   

The Black Fin is a peer-to-peer game cart sharing device for PS Vita that was released in September 2016. Now the lead developer behind the Cobra Black Fin has partially leaked info from the project and shared his experience developing it with

The hacker states he has 76GB of reverse engineering data related to the PS Vita (the bulk of it being dumps, logs, but also, he says, some juicy stuff), the result of 4 years of work on the cobra blackfin project.

Apparently the developer never got paid by the Cobra producer.

Unfortunately, I was stupid and too trusting, and the contract was for payment on delivery of the product and the guy running the Cobra business sc*** me of over 4 years of work by not paying after I delivered the product.

What I remember about the Black Fin was that Sony changed something in firmware 3.60 which pretty much killed the product just before launch as it only supported firmware 3.57 and below.

Another drawback was that you had to rely on P2P servers for non owned games, this infrastructure depends on having many active users sharing games which turned the product into a Catch-22 situation due to the firmware limitation and relatively high price.

The final nail in the coffin for Black Fin was HENkaku which is a free homebrew exploit enabling softmod released by team molecule not long after product launch.

[ This message was edited by modrobert on 2017-09-18 @ 00:01 GMT ]
  _____________________________ ____________     __________________ /\________
  \    __________________      \      _____/____/     _    \       /_        /
 /     /       |       l/     _/    ____)     _/      _     \     \/  cREAM /
/______________l_______/       \______________\_______|      \_   /________/
 -+--Mo!-------------- \________/ ------------------- l_______/_____\ -----+-

 Profile  pm  www    Quote


Registered: 2003-10-17
From: Bangkok
Messages: 6240
Status: Online
 _#35662 posted 2017-09-13 @ 15:47 GMT   
...and the first download:

BlackFin Design Dump R1

[ This message was edited by modrobert on 2017-09-13 @ 15:49 GMT ]
  _____________________________ ____________     __________________ /\________
  \    __________________      \      _____/____/     _    \       /_        /
 /     /       |       l/     _/    ____)     _/      _     \     \/  cREAM /
/______________l_______/       \______________\_______|      \_   /________/
 -+--Mo!-------------- \________/ ------------------- l_______/_____\ -----+-

 Profile  pm  www    Quote


Registered: 2005-06-12
From: Germany
Messages: 3
Status: Offline
 _#35735 posted 2017-10-23 @ 09:28 GMT   
The Dev befind the Cobra Blackfin has released the second "leak" of his work, also he explains some "scene drama".



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Ē [1] 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Ē[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.



Notes + Contents of the archive

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: Documents
You can find the schematics, BOM, CAD, PCB, and gerber files for the Dongle here :
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 :
More precisely, itís an old checkout that I never bothered to update, it is based on commit d1370b2cc7cc986b712e1a27a49b23a9eadb3cec from April 3rd 2012 ( 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
* 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
* 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.
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

Download: see attachment below

[ This message was edited by hitman43 on 2017-10-23 @ 09:33 GMT ]


 Profile  pm    Quote
New Topic   Post Reply
Jump To

All trademarks and copyrights on this page are owned by their respective owners.
Comments and forum messages are owned by the Poster.