Close. These algorithms only work correctly if implemented correctly. There are various known pitfalls with each of these algorithms; for example, the original iPhone was unlocked using an RSA implementation error (Bleichenbacher attack against an RSA implementation that does not correctly validate padding and uses exponent 3). ECDSA happens to have a "pitfall" that leaks information inside the signatures it makes.

This doesn't make it a bad algorithm -- it can achieve the same security of RSA using smaller keys and in less time -- but the "pitfall" here is particularly bad.

No, GP was right. The exact signing key used by Sony may be derived from the public components of their ECDSA signatures. Not something close; not something equivalent.

Click through the links to the actual Kickstarter project description. We did some handwaving to keep it accessible for J. Random (Software) Hacker, but I think we gave enough details to answer your questions.

(tl;dr: yes, you're right, and that's more or less what we're doing. Haven't decided on which PHY to use, looking at some SMSC and NXP parts.)

OpenVizsla will be a completely open design of a device that can capture USB 1.1/2.0 (high-speed, full-speed and low-speed) traffic passively between a target USB device and the connected host (usually a PC, but potentially anything that has a USB host port -- think Xbox 360 and PS3). It will be controlled by any computer using open-source client software or potentially in standalone mode (where captured traffic is stored onto an on-board SD card).

As is proper for any open and hackable design, unused I/Os on the FPGA will be exposed (via 0.1" header) for use as a primitive logic analyzer. We hope to eventually support additional sniffing interfaces (SPI, I2C RS232, SD card etc) that connect to a high-speed Mictor connector that can act as 'man-in-the-middle' and extend the device capability limitlessly.

The OpenVizsla device is built around a multi-layer PCB with around 180 surface-mount components that allow the target USB packets to be captured, buffered and delivered to the PC (or stored on SD card in standalone mode).

An XMOS event-driven processor will handle the huge amount of USB data (these little chips are fast!) and it will handle the overall communications with the host (which will be a fully published protocol!) and will provide on-board system programming, housekeeping and of course flash the status LEDs! In standalone mode, the XMOS chip will handle data acquisition and SD card storage; this processor is fully reconfigurable and can be modified and reprogrammed to improve the features or adapt to new requirements.

For the high-speed USB signals a Xilinx Spartan3E FPGA (with attached, expandable RAM) will capture, process and buffer the USB traffic from an attached USB transceiver that we use to deserialize the USB signals from the target link.

It's a subject of some debate. The Xbox homebrew scene, as I understand it, used files directly copied from a leaked Xbox SDK. libnds uses some code that is more or less directly translated from disassembled DS SDK code (though you can get most of the same code from dumped games anyway); some feel that this is morally / legally equivalent to just copying the files.

Sure -- if Sony decides to ban you, you've already messed up. Sony can't "decide to ban you" if they can't tell you've done anything naughty, so it's better to avoid permanent changes to the console that can be detected by their software.

What makes you say that?

Care to explain what PCB traces are shared between D+/D- on the USB and the RAM? And what this has to do with your TomTom?

You're also confusing the service mode jig used in Sony repair centers on retail consoles with debug consoles used for development. The two are unrelated.

It's also worth pointing out that Rigol apparently makes some of Agilent's low-end scopes for them, so the fact that they aren't a household name doesn't mean all that much.

The Rigol scope has a lot of nice features that you wouldn't expect to find on a cheap scope -- it can take screenshots and store them to a USB thumb drive or print them to a USB printer, you can connect it to your computer to control it or acquire data via USB or RS-232, etc. It actually oversamples at 1 Gigasample/second -- there have been a number of EEVblog shows about it, talking about its performance, the parts that go into it (and the corners they did cut to get the price down!), etc. Google "eevblog rigol" to find the rest of them.