iSuppli's business model revolves around finding you low prices for components (for a nice, hefty fee, of course) for your next big consumer electronics product; these teardowns are just advertising for that service. In order to pull customers in, they mark down the lowest plausible price for each component; it's unlikely that even Apple can get these low prices for each component.

Practially every teardown they show is low-balled, because there's no way to verify any of these numbers, and lower numbers gets them more contracting business.

This is well-written, but mostly incorrect, based on some bad assumptions about sandboxing and encryption.

No, the iOS sandbox is stronger, in that it supports more fine-grained control over access to individual syscalls (based on the BSD-heritage Mandatory Access Control framework), as well as the API-level and filesystem permission-level isolation that Android relies upon. Jailbreaks didn't rely on a lack of sandboxing, for the most part -- they exploited kernel bugs in e.g. the graphics driver. It took until 2011 that "rooting" on Android even approached the complexity of the 2008 iPhone exploits; the neccesary exploits on Android were generally much simpler.

This is only partially true. Android most certainly does distinguish between "system apps" and 3rd-party apps -- why do you think people have to root their phones to remove crapware?

The main reason that Android's permissions UI is more complex is ... a design issue. The Android team decided that it was better to make all users click through a screen showing a bunch of scary shit, so that they could later blame the user if the app does something strange. "Dialog fatigue" ensures that very few people actually read the whole UI, and the fact that you can't (on a stock system) individually deny any access (while still using the app) means that most people just suck it up and run the app and take their chances.

Most of the rest of what you wrote is wrong, because you base it on the statement that Android's sandbox is stronger.

Okay, now go back and actually read the Apple paper, starting with page 8. iOS's encryption is fine-grained -- the whole partition is encrypted, and then individual files are further encrypted, depending on the application and use (e.g. you can receive new email and take new photos while the phone is locked; that stuff is then encrypted and written to flash, and cannot be accessed until you unlock the phone with a PIN. Older contents cannot be decrypted until you unlock the phone). Android only got encryption with 3.x and 4.x -- about 2 years after it appeared on iOS -- and it's a shitty implementation (requires a full battery, AC power, and > 1 hour to enable or disable; any interruption will cause data loss; must enter PIN code on boot, which then causes the whole flash to be decrypted in memory until you turn the phone off).

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.