Actel ProASIC 3 a3p250

L

LagSwitcher

New member
Joined
Jul 8, 2019
Messages
3
Hello,

I’m looking for any info on how to extract code from the mentioned FPGA in the title.


I’m asking in regards to the Wiikey/Wasp fusion modchip. The chip, IMHO, is the best modchip for the Gamecube available but sadly is no longer in production. As my own stock is running dry and available stocks on obscure modding websites ask way the much for this once cheap modchip, I would like to, if possible, start reproducing this modchip.

I’ve reached out to a couple China based companies that specialize in Decapping and code extraction, but non seem to be willing to tackle the FPGA.

I know Citrus3000psi and meneerbeer have come with a new product that is very interesting, It still lacks the passthru ability the original Wiikey and Wasp have to be able to retain the DVD drive functionality.

Any help or gentle push in the right direction is welcome.
 
I don't think you are going to have much luck - those devices are famously resistant to attack. In order to read them out over the ISP port you need both a flash lock code (128 bits) and the AES key that the configuration was encrypted with (also 128 bits) - on a physical level, the flash cells are buried under multiple layers of metal (7, IIRC) and even if you can read the raw data you still need the key which is programmed into different flash cells in the configuration engine.

I've heard people claim they have been cracked, but everyone I've ever talked to that attempted it failed.
 
Isn't the Wasp a clone? That'd mean someone already got at the bitstream.
 
FamilyGuy said:
They may also have had access to the source. Social engineering works best.
Click to expand...

I suspect they just had the bitstream rather than the source - this is admittedly a guess, but supported by the fact that the Wasp was really a 1:1 clone of the Wiikey. On top of this, after Microsemi bought Actel they really jacked up the price of those ProASIC parts (presumably to encourage people to migrate to something else) and it's reasonable to assume that if someone had access to the source they would have resynthesized it for some cheaper and more readily available chip.
 
Yup, the "1:1 clone w/o source" bit is what I heard too.

> really jacked up the price ... to encourage people to migrate

Indeed, iirc I looked into them at some point and they're anything but cheap. That doesn't seem to deter our mister LagSwitcher over here. :p

Honestly, if something like passthrough mode were important to me (which it isn't because one can just pick up a cheap second console to rip stuff with), I'd rather try getting it added to an actively maintained device.
 
Trimesh said:
I suspect they just had the bitstream rather than the source - this is admittedly a guess, but supported by the fact that the Wasp was really a 1:1 clone of the Wiikey. On top of this, after Microsemi bought Actel they really jacked up the price of those ProASIC parts (presumably to encourage people to migrate to something else) and it's reasonable to assume that if someone had access to the source they would have resynthesized it for some cheaper and more readily available chip.
Click to expand...
I'm not very knowledgeable in FPGAs, although I would like to change that in the mid term future.

What I meant is that they probably had access to the files to flash the FPGAs instead of reversing them.

IIUC what you're telling me is that they had a bitstream, basically a compiled code to flash on the FPGA?, but not the original source itself?
 
Last edited:
My FPGA-fu isn't the strongest either, but yes, "bitstream" is FPGA-speak for the "compiled" (synthesized) "code" (device programming info, basically its "circuitry configuration"). Unlike PC program code it cannot, as far as I know, reasonably be reverse engineered (please let me know if I'm wrong about this), so you can't move stuff to a different device without access to the source code.
 
Allow me to say something stupid please! Or rather, ask a stupid question.

Considering FPGAs are just lots of gates that are able to be programmed, could you get some sort of logic analyzer and make pins blah go high and check output, then put it into a Karnaugh map or make it into boolean algebra, and then simplify to find the gate combination? Or is there so much more in a FPGA that this isn't possible? I highly doubt it is possible, but I know nothing about FPGAs... so hit me!
 
supersega said:
Allow me to say something stupid please! Or rather, ask a stupid question.

Considering FPGAs are just lots of gates that are able to be programmed, could you get some sort of logic analyzer and make pins blah go high and check output, then put it into a Karnaugh map or make it into boolean algebra, and then simplify to find the gate combination? Or is there so much more in a FPGA that this isn't possible? I highly doubt it is possible, but I know nothing about FPGAs... so hit me!
Click to expand...

The short answer is that FPGAs don't just consist of gates - they also have flipflops and RAM and other elements that contain persistent state. As a result, the output values for any given input values might in principle depend on any or all of current values of the devices internal state. This specific device contains 6144 logic cells ("tiles" in Actel parlance), each of which contains flipflop (I.E. potentially 6144 bits of retained state) - it also contains 26kbits of RAM storage, which could also potentially change it's response. If you treat all those bits as being potential state then you end up with a search space of about 2^32000 - which when expressed in decimal is a number about 10,000 digits long and far too large to be even potentially searchable.

cta said:
My FPGA-fu isn't the strongest either, but yes, "bitstream" is FPGA-speak for the "compiled" (synthesized) "code" (device programming info, basically its "circuitry configuration"). Unlike PC program code it cannot, as far as I know, reasonably be reverse engineered (please let me know if I'm wrong about this), so you can't move stuff to a different device without access to the source code.
Click to expand...

You can ... sort of ... reverse engineer them. If you manage to pull the bitstream you can generally reverse it into a technology independent netlist format describing a list of logic elements and the interconnections between them. The problem is that this is typically a much lower level of abstraction than the original code was working at, and it can be hard to work out what parts of the implementation were actually a reflection of the designers intent and which were just "stuff" that the place and route tools did. Most FPGAs also have device (or family) specific megacells, and once placed these can explode into a huge number of primitives that then get packed into cells with other functions and can be hard to identify.

This approach has been used successfully to move designs from one device to another similar device in the absence of the original source code - but if it doesn't work then you are pretty much screwed since you no longer have access to either the designers intent nor any layout constraints they might have placed on the original design.
 
For one, you're not acknowledging the temporal component there. These things can have internal state. Example: What if pin $FOO goes high only once $BAR has been clocked N times (and even then maybe only if $BAZ and $YORP have not been pulled low at any point during that period)?

edit: ninja'd. answer was aimed at @supersega
 
Also, I'm pretty sure I read you can keep the original drive too with the gc loader.
 
It's meant to occupy the original drives' space inside the shell, so even if you technically could have them both connected up, it'd make for an interesting setup - with the ODE board hanging out the side or something. Then again a Wiikey-on-GC setup doesn't look very "stock" either if you decide to keep the drive, so... meh.
 
Ah shucks, gotcha there folks. Guess I was true when I said I knew next-to-nothing about FPGAs!
 
Bad_Ad84 said:
Also, I'm pretty sure I read you can keep the original drive too with the gc loader.
Click to expand...
With the GC Loader, your DVD drive becomes unusable. That's the main problem with this ODE («hey, we aren't for piracy, but you can't dump your games with GC Loader installed»), the second one is the SD card (and not micro SD)
 
Djelaba said:
the second [problem] is the SD card (and not micro SD)
Click to expand...
Not in my book, since a) regular sized SD cards are much less fiddly to install, which is appreciated every time you need to swap one. (Or can the whole GC library fit on a single card, which would render that whole issue moot? Haven't checked [edit: I have now, and 1TB really should be enough for everyone].) and b) you can just use an adapter if you insist on using a (slightly more expensive) micro in there; the other way round? Harder.
 
Last edited:
Using a micro SD card would help reduce the size of the PCB, or use the extra space to add passthrough.
 
You must log in or register to reply here.
Back
Top Bottom