ARM supports both endiannesses, and most if not all heavyweight mobile devices these days are configured in little-endian mode. To user-level C software not using inline asm, ARM looks very similar to x86. The main difference is ARM support for unaligned accesses is nonexistent in earlier chips and incomplete in newer ones, but you can have the OS trap those and emulate them (at a significant performance penalty, but depending on how often they happen that might not matter).
People weren't trying until OtherOS got removed, and that happened after geohot glitched the memory bus. Given what we know about the PS3 at this stage, I can tell you that there would've been plenty of easier avenues of attack from a black box perspective. For example, there are more than a couple fun header validation bugs that you can try to exploit just by dumping out the NOR and doing some analysis on the binaries contained within. Dumping out Flash memory and messing with it is standard operating practice for trying to break into a device these days (if you know what you're doing), and it's a hell of a lot more reliable and clean than trying to glitch the memory bus. Or, another nice vector (which was actually already known before the HV exploit) was the broken HDD encryption. Given enough effort, you can decrypt the entire PS3 HDD, change any data, and encrypt it again (this was known), so all it would take would be exploiting a bug in a file parser for some system file. Geohot decided to have some fun when no one else cared, and chose an awkward and unreliable course of action - that doesn't mean that was the only course of action.
Also, you're wrong when you say that you can't defend against memory glitching attacks. The 360 does precisely that - hypervisor memory is hashed and encrypted. As for power and clock glitching, that's enormously more complicated (likely practically impossible) on a system using a Cell than it is on a Gameboy Color's Z80.
Remember, the countdown for the time it takes to break a security system starts when competent people start trying to break into it. I've worked with some of the most well-known and competent embedded device hackers out there, and I can tell you that nobody was having a serious go at the PS3 until they nuked OtherOS. It wasn't seen as a priority or nearly as interesting as other devices, since it came with a built-in (albeit gimped) "homebrew mode". If you start counting when OtherOS was removed, the PS3 lasted less than its competitors.
And yes, the PS3 security system is a clusterfuck of everything-and-the-kitchen-sink-done-wrong. They like to use HMACs as a hash function for no reason - both wrapped in public key signatures, and not (!). They misuse counter modes for block ciphers and reuse keys. They fail to validate headers. They have an excessively poorly defined and awkward security container format. They don't wrap things in public key signatures at the earliest possible place, and handle and parse way too much untrusted data. They don't use W^X on the OS kernel (that's what made the USB exploit possible). Privilege separation is leaky. They have an excessively complicated hypervisor that isn't even designed with security in mind. It's way too easy to patch and/or emulate your way around security checks. Their full disk encryption is hilariously broken (Fixed IVs! No hashes! You can decrypt anything you want by putting the HDD into a computer, swapping blocks around between a user file and "secret" system data, then putting it back into the PS3 and copying out the user file). They even use custom cipher operation modes in places, like CBC except they switch to CFB for the last non-multiple-of-the-blocksize chunk. As mentioned, they made the worst possible mistake when implementing their ECDSA signer, and leaked their secret private keys to the world. Worst of all, the overall architecture is ass-backwards, and you can pirate PS3 games by breaking only 10% of the security, which completely defeats the purpose.
Sorry, but there's no excuse for that amount of fail. The PS3 has the worst security design of this generation, and the only reason it lasted as long as it did was because they had an alternative (OtherOS). Well, that, and maybe because people bought a bit into the kool-aid and buzzwords and thought it'd be a hell of a lot more secure than it turned out to be.
The same Powerpointology that was used to design the PS3 security system. It includes just about every single crypto buzzword and system under the sun. AES, RSA, Elliptic Curves, CBC, ECB, CTR, CFB, RC4, SHA1, MD5, HMAC, SSL, Full Disk Encryption, Isolated Security System, Hardware Decryption, Secure Boot, Per-Console Encryption, Tokens, Hypervisor, blah blah. You name it, it's in there, used in all the wrong ways and littered with holes.
This is the problem with Sony: they do Security by Powerpoint. Buzzwords a secure system do not make.
Nintendo's security designers at least knew what they were doing, since the Wii's security design is logical, consistent, quite simple (simple is better), and uses the right technologies in the right places. Sadly, their code monkeys failed at coming up with an implementation with fewer holes than swiss cheese. Microsoft is the best of the bunch, as they have a solid, powerful security system with an extremely good implementation so far.
Mod parent down for perpetuating a useless, incorrect key that just won't die.
That's the USB dongle service mode authentication key, which is useless for breaking PS3 security except as an accessory to some now-disabled functionality that requires leaked service executables. In other words, it's 1) impossible to use legally, as you need to infringe copyright to use it, 2) useless since a few updates ago, 3) won't help you break into lv2, 4) won't help you break into the security system, 5) won't help you break the chain of trust, 6) won't help you run Linux.
It was only ever used as part of a commercialy distributed firmware downgrade trick designed for a commercially distributed piracy tool.
Now can we please switch over to a relevant string of hex digits when talking about PS3 security? Please? I suggest "Da" from geohot's keydump, which is the metldr private key, and infinitely more relevant than this 46 DC nonsense.
About as amateur as using a static constant instead of a random number when signing firmware and games, which is exactly what they did (and which pretty much cost them their entire system security).
Dual GPUs would not be any more expensive than the PS3.
They wouldn't be any more expensive than the launch PS3, but if that's your benchmark for cost optimization you have bigger issues.
Besides if Nintendo wanted to hit a specific price point, they could easily do it. Even if it meant that they lost money on the console this time. Just because the Wii made a profit from day 1, does not mean that they have to do the same with the Wii 2.
Nintendo doesn't do the whole selling below manufacturing cost thing, and I've seen no indication that they're suddenly going to start doing it.
I think Sony is still loosing money with every PS3 console sale.
They aren't. Not for quite a while now. But they used to haemorrhage money, since the original launch PS3 was just about the most pathetically cost-unoptimized product I've ever seen. Stuff inside it: a built-in standalone Ethernet-to-WLAN AP for wireless connectivity (instead of, you know, a WiFi card), an 8-port Gigabit switch with VLAN support, a standalone NAND controller including FTL layer, a 4-port USB 2.0 hub, an IDE-SATA converter chip, a chipset with a die larger than the CPU (because it had a memory controller, video output, PCI Express, multiple support CPUs and a ton of other crap that they don't use), and of course an entire standalone PS2. Not to mention enough BGA chips to make assembly yield specialists cringe. They trimmed some stuff with the later Fat revisions, but until the release of the Slim most of it was still there. The Slim is the first non-WTF PS3 design, as far as cost-optimization.
The PS3 started out with an utterly batshit insane design, then eventually arrived at something roughly resembling what they should've been shipping from day one. The Wii started out with a perfectly reasonable design, then later revisions have been micro-optimizing cost here and there so now they have an incredibly optimized design. I somehow doubt Nintendo is going to go the way of the PS3 for next generation.
"GPU calls"? It'd have to support the entire architecture and register and command set, verbatim, even as far as having the same cycle by cycle performance characteristics if they don't want issues with some games. That is far from "easy". In fact, I'd say it's almost impossible, short of, as you mention, having two GPUs in it. But having two GPUs would be expensive.
Of course nobody expected Linux to be on the Slim (and nobody can complain that they don't have linux on their Slim). I'm just pointing out that removing Linux from the Slim (which in and of itself is fine) is related to removing Linux on the Fat, which isn't. The underlying reason is almost certainly the same, and it's neither (legitimate, i.e. Slim-only) cost saving nor geohot's hack.
I should point out - Sony had decided that the PS3 slim would never have OtherOS support long before this happened, but that's ok
It isn't OK, actually. Not because it's illegal or wrong (they have every right to do it), but because they lied about their motive. It that further confirms that they lied about why they removed Linux on the Fats.
They claimed they removed Linux from the Slim due to cost saving reasons, but now we know that Linux "just works" on the Slim because it runs on top of the same hypervisor that GameOS uses. In other words, maintenance cost was implicitly zero due to the way the PS3 works, and they actually had to put more development time into removing Linux than they would've if they'd just left it there. This means that they had a reason to remove Linux a long time ago already.
They lied about why they removed Linux on the Slim, and we don't know their real reason. It follows that they lied about why they removed Linux on the Fat; they were just itching to remove it for the same (unknown) reason they did on the Slim. The Geohot hack was just a poor excuse that they could use.
One possible explanation is that they were planning on removing Linux across all consoles all along to save money in the long term (simply because they wouldn't have to support the tiny launcher in future firmwares - this doesn't save money if you only do it on the Slim, but it does save some money if you do it across all consoles). Or maybe there's an entirely different reason that we don't know about.
People are going to reply that either 1) it was used to break into the console and pirate games/break DRM/hack online games, or 2) it was costly to maintain. Those are what Sony would like you to believe. However, both of those are lies.
It is true that the first remotely notable break in PS3 security occurred through the use of the Linux functionality. This was geohot's original hypervisor exploit. However, that exploit required hardware (a RAM glitching setup), was extremely unreliable, and didn't get you any further than hypervisor access. Nothing ever came out of that hack directly, it was more of an academic thing. This has never had anything to do with piracy and has never been used for piracy.
The next big PS3 hack (which was actually designed for piracy) was a GameOS exploit (PSJailbreak), and later the core of the PS3 security was compromised, with the goal of running Linux, but without depending on any existing Linux functionality (which had been removed by then). So, in fact, OtherOS has never caused security problems from the PS3. In fact, the only thing it clearly did was prevent attack by giving power users a way to run their own code. The vast majority of people who I know participated in developing PS3 hacks (myself included) did so after Sony removed OtherOS, and wouldn't have done so otherwise.
So that takes care about option #1. What about #2? That's what Sony implied when they removed OtherOS from the PS3 Slim (which, remember, happened before any PS3 security issue at all). And we bought it at the time. And then the PS3 security was broken, Slim included, and we found out that GameOS uses the same hypervisor interface as Linux, and that Linux happily ran on the Slim with trivial modification. The truth is that GameOS depends on the same hypervisor as Linux, and OtherOS is nothing but a launcher and a different guest profile in the hypervisor. The amount of code required is insignificant, and the maintenance required just about nonexistent. By maintaining GameOS they are implicitly maintaining OtherOS. High maintenance cost? My ass. This also exculpates geohot's original hack, since that happened after Linux was removed from the Slim, and we now know that the given reason for removing it from the Slim was bullshit.
Then there's the whole selling PS3s at a loss deal, but we all know that Sony is now making a profit on all PS3s, so Linux doesn't hurt there either.
They turned it off because they WANTED to turn it off. The real motive? There clearly is one, but we don't know what it is. The only mildly plausible explanation that I've read is that Sony wanted to push emulated PSN games a la Virtual Console, but studios were concerned about unofficial emulation via Linux. But that's still not terribly convincing.
Note: I was one of the people named in the Sony lawsuit for bringing Linux back on the PS3, so I think I know what I'm talking about.
Try PowerPC 970 . Which isn't exactly identical to the PPC CPU cores in the 360 or the PPU core in the PS3, but it's a reasonable comparison, at least as far as feature set.
The Wii doesn't emulate the Gamecube, it is a Gamecube. Just at a higher clockrate and with more peripherals. To run Gamecube games they turn those off and drop the clock rate.
They can't do that again with the Wii2 because they really need a new GPU now. This little stunt worked because the Gamecube GPU was pretty decent for its time, but if they churn out another console with the same old GX GPU they're going to be the laughingstock of the games industry (no shaders, tiny framebuffer, useless antialiasing modes... won't fly in 2012).
They're going to have a hard time retaining backwards compatibility in a sane manner. The CPU is easy, as long as they stick with PowerPC. But the GPU isn't abstracted out and games talk directly to the hardware. The Wii's GPU hasn't changed since the GameCube (other than clockrate), but this time around they really need a new design with proper modern features like shaders. There are four options: design a new chip that's still backwards compatible, use a new chip and emulate the old in software, keep the old chip around just for backwards compat, and just ditch backwards compatibility.
#1 is unlikely because the Wii's (and Gamecube's) GPU is very divergent compared to modern GPUs, and I somehow doubt AMD will make a complete refresh of that architecture for them, incorporating modern features while retaining 100% backwards compatibility. It'd basically be designing a modern GPU from scratch, and retaining compatibility would be a nightmare. #2 is plausible (heck, I maintain that full Wii emulation on the PS3, a current gen system, is possible), but they're going to have to put a lot of effort into making a near perfect emulator or people are going to complain. #3 is wasteful; this worked for Nintendo in the handheld space where graphics processors weren't exactly overly complex (until the 3DS at least), but I don't see them doing it with a console GPU (Sony did this and we all know how they ended up selling at a loss partly because of it). #4 is eminently possible (and it's not like this is new for Nintendo in the console space - the Gamecube to Wii compatibility was the exception for them, not the rule). I'm going to vote for #4.
And Sony is in a similar situation because, even though the PS3 does have a real OS and dynamic linking, they had the bright idea of linking in the GPU command stream drivers statically into games, so PS3 games are hardcoded to issue NV47 FIFO instructions and good luck getting them to run on any more recent NV architectures.
Imperial is going away in this field. PTH stuff is specified in thousandths of an inch because of the standardized 2.54mm=0.1" pin spacing, and SO-package (and PLCC) surface mount just halved that distance. However, most smaller surface mount packages are specified exclusively in millimeters. I switched my CAD grid from mils (of an inch) to millimeters quite a while ago, because it makes a lot more sense since it increases the chances of your smaller package pins falling on the grid, while you don't really care about the (relatively) huge PTH and SO package pins. Design in imperial makes sense if you're doing old-school PTH kits and you want everything on a nice 0.1" grid, but not otherwise.
If you take a projector, be it dots or multimedia, and a camera right on top of it, the projection as seen by the camera will be exactly the same size within the camera's field of view regardless of how far away the wall is. If you move the wall back, the projection increases in size at the wall, but the wall (with the projection) decreases in size as seen from the fixed camera. The two effects cancel out.
The simple trig will give you the nominal separation at the surface. Then, when you run the trig in reverse to calculate the pixel separation at the camera... you end up with exactly the same reparation regardless of depth. The camera has a radial field of view just like the projector, and pixels correspond to a fixed angle. Since the camera and the projector are on the same plane, it cancels out. Ignoring brightness (which is unreliable) and dot size (which isn't accurate enough), a flat far surface looks exactly the same as a near flat surface, except one will be horizontally shifted as a whole when compared to the other.
Many people make this mistake, probably because they're imagining the pattern from a steep angle when viewed from outside the Kinect (or have seen YouTube videos to that effect). Our brains are also very good at associating the same angular (pixel) separation on an object that is (apparently) far away with a larger actual separation (this is why those optical illusions where two objects look different in size due to false depth cues work). However, when you view the pattern from the Kinect on the same plane as the source, and ignoring any previous knowledge of how deep parts of the image are (since, of course, finding out is the whole point), the average separation between dots is the same across the entire depth range where local depth difference is zero. Separation between dots is proportional to the derivative of the depth (local depth difference) only, but it is not proportional to absolute depth.
For example, look at this IR dot image, as seen by the Kinect (note: half resolution, since getting the fullres raw image out via USB is problematic). If you look closely and ignore the varying dot brightness and dot size (the dots are laser beams so the virtual point source for each beam is very far behind the Kinect, and thus isn't on the same plane as the camera so dot size varies as seen by it), you'll see that the dot density is basically the same across all depths (measured in dots per area, not dot pixels per area - don't be misled by the larger dots on surfaces near the camera).
It sees horizontal dot displacement... as compared to an internal calibration reference image. There's an internally stored reference image (either as an actual image, a set of dot coordinates, or perhaps just a calibration matrix if the dot pattern is fully predictable - we don't know specifically how it's stored). If you watch a video of the IR dot image it's very easy to see how the dots move left and right as objects move near and far, but there's no way to tell the precise depth of a point in the image without a reference image to compare to.
Displacement is distance, but (distance|displacement) between different dots in the captured image isn't the same as (distance|displacement) between a dot and its counterpart in a reference image.
Put another way, the Kinect sees almost the same image when it looks at a wall 1m from it and a wall 5m from it (other than brightness, but that also isn't part of the algorithm because it varies depending on the material). The only difference is that one is horizontally shifted from the other. It is this absolute shift (which is compared against an internal calibration image) that is used to calculate depth. Without the reference image and the absolute comparison there would be no practical way to obtain an absolute depth measurement from an image like that.
Yes, dot distance does correspond to the slope of the depth, but then you'd have to integrate the resulting measurements to measure depth (that, and the dot field isn't a pattern, it's pseudorandom, so there's no trivial way to know how far apart dots are supposed to be in the first place). This isn't what the Kinect does; it directly correlates dot clusters to a reference image and measures absolute displacement against it.
Not the distance between dots. The camera sees exactly the same dot density regardless of depth because the projector and the camera are on the same plane (it doesn't matter if the surface is near or far, since dots will have the same angular distance when viewed from the camera). What it does measure is horizontal displacement vs. a reference image. This works because the camera and the projector are horizontally offset.
PrimeSense developed the sensor technology (hardware and firmware) that gives you a depth image. Microsoft took that depth image and created the algorithms that perform body tracking (software).
PrimeSense also have their own body tracking solution (they call it NITE), but it's based on an entirely difference concept and requires a calibration pose to "lock in" initially. Microsoft doesn't use NITE.
This has nothing to do with reconstructing a depth image from a 2D image. The Kinect is a depth camera and already gives you a real depth image (not a guess).
It's not the key that lets you sign your own code. It's not the key that lets you decrypt the OS. It's not the key that lets you decrypt games. It doesn't let you do anything interesting. Huh? What? Yes, you heard me.
It's a useless key that is used to authenticate factory service dongles (which will only let you run signed executables anyway, and those signing keys are secure as of the latest firmware and will never be obtained). Its only purpose so far was to perform downgrades (as released in a commercial product using stolen service executables) in order to use another commercial product (by ostensibly the same company) which used an exploit to enable game piracy (using a whole bunch of other methods unrelated to it). All of this predated the 27c3 presentation and geohot's release. It's useless now and has never served any "master" key purpose. It was called the "master key used to generate service dongle keys", then of course the clueless news websites just shortened that to "master key".
The PS3 has tons of keys and you can't "do everything" with one key. You need three or four to run stuff via metldr, that's why geohot released a whole bunch of keys, not just one (none of which are the one that was used here). But if you must pick one "representative" key to obfuscate and post and distribute and make an icon out of, at least pick Da from geohot's keyset (starts with C5). That's the metldr private key, originally stored at some vault at Sony's HQ, calculated thanks to their massive signing screwup, and which can be used to sign code that all existing PS3s will execute, forever (you still need to encrypt it, but signing is ideologically more important). And for fuck's sake, please let go of the "46 DC" dongle key already. Please.
And using a SPI interface to control it is like using Lego as a drive train from the V8 to the rest of the car.
But, you see, anything with Arduino in the name is instamagically popular. As stupid as using an Arduino is, this project has a much bigger chance of success as an Arduino shield than as a standalone board.
I'm too lazy to check, but I'm willing to bet there are Arduino shields out there that only use the Arduino for power.
Slashdot Mirror
ARM supports both endiannesses, and most if not all heavyweight mobile devices these days are configured in little-endian mode. To user-level C software not using inline asm, ARM looks very similar to x86. The main difference is ARM support for unaligned accesses is nonexistent in earlier chips and incomplete in newer ones, but you can have the OS trap those and emulate them (at a significant performance penalty, but depending on how often they happen that might not matter).
People weren't trying until OtherOS got removed, and that happened after geohot glitched the memory bus. Given what we know about the PS3 at this stage, I can tell you that there would've been plenty of easier avenues of attack from a black box perspective. For example, there are more than a couple fun header validation bugs that you can try to exploit just by dumping out the NOR and doing some analysis on the binaries contained within. Dumping out Flash memory and messing with it is standard operating practice for trying to break into a device these days (if you know what you're doing), and it's a hell of a lot more reliable and clean than trying to glitch the memory bus. Or, another nice vector (which was actually already known before the HV exploit) was the broken HDD encryption. Given enough effort, you can decrypt the entire PS3 HDD, change any data, and encrypt it again (this was known), so all it would take would be exploiting a bug in a file parser for some system file. Geohot decided to have some fun when no one else cared, and chose an awkward and unreliable course of action - that doesn't mean that was the only course of action.
Also, you're wrong when you say that you can't defend against memory glitching attacks. The 360 does precisely that - hypervisor memory is hashed and encrypted. As for power and clock glitching, that's enormously more complicated (likely practically impossible) on a system using a Cell than it is on a Gameboy Color's Z80.
Remember, the countdown for the time it takes to break a security system starts when competent people start trying to break into it. I've worked with some of the most well-known and competent embedded device hackers out there, and I can tell you that nobody was having a serious go at the PS3 until they nuked OtherOS. It wasn't seen as a priority or nearly as interesting as other devices, since it came with a built-in (albeit gimped) "homebrew mode". If you start counting when OtherOS was removed, the PS3 lasted less than its competitors.
And yes, the PS3 security system is a clusterfuck of everything-and-the-kitchen-sink-done-wrong. They like to use HMACs as a hash function for no reason - both wrapped in public key signatures, and not (!). They misuse counter modes for block ciphers and reuse keys. They fail to validate headers. They have an excessively poorly defined and awkward security container format. They don't wrap things in public key signatures at the earliest possible place, and handle and parse way too much untrusted data. They don't use W^X on the OS kernel (that's what made the USB exploit possible). Privilege separation is leaky. They have an excessively complicated hypervisor that isn't even designed with security in mind. It's way too easy to patch and/or emulate your way around security checks. Their full disk encryption is hilariously broken (Fixed IVs! No hashes! You can decrypt anything you want by putting the HDD into a computer, swapping blocks around between a user file and "secret" system data, then putting it back into the PS3 and copying out the user file). They even use custom cipher operation modes in places, like CBC except they switch to CFB for the last non-multiple-of-the-blocksize chunk. As mentioned, they made the worst possible mistake when implementing their ECDSA signer, and leaked their secret private keys to the world. Worst of all, the overall architecture is ass-backwards, and you can pirate PS3 games by breaking only 10% of the security, which completely defeats the purpose.
Sorry, but there's no excuse for that amount of fail. The PS3 has the worst security design of this generation, and the only reason it lasted as long as it did was because they had an alternative (OtherOS). Well, that, and maybe because people bought a bit into the kool-aid and buzzwords and thought it'd be a hell of a lot more secure than it turned out to be.
The same Powerpointology that was used to design the PS3 security system. It includes just about every single crypto buzzword and system under the sun. AES, RSA, Elliptic Curves, CBC, ECB, CTR, CFB, RC4, SHA1, MD5, HMAC, SSL, Full Disk Encryption, Isolated Security System, Hardware Decryption, Secure Boot, Per-Console Encryption, Tokens, Hypervisor, blah blah. You name it, it's in there, used in all the wrong ways and littered with holes.
This is the problem with Sony: they do Security by Powerpoint. Buzzwords a secure system do not make.
Nintendo's security designers at least knew what they were doing, since the Wii's security design is logical, consistent, quite simple (simple is better), and uses the right technologies in the right places. Sadly, their code monkeys failed at coming up with an implementation with fewer holes than swiss cheese. Microsoft is the best of the bunch, as they have a solid, powerful security system with an extremely good implementation so far.
not very obviously break the production site by dumping the entire fortune file out with every page.
World to Slashdot calling, it would like you to know about little tiny things called "testing environments". You should learn about them.
Mod parent down for perpetuating a useless, incorrect key that just won't die.
That's the USB dongle service mode authentication key, which is useless for breaking PS3 security except as an accessory to some now-disabled functionality that requires leaked service executables. In other words, it's 1) impossible to use legally, as you need to infringe copyright to use it, 2) useless since a few updates ago, 3) won't help you break into lv2, 4) won't help you break into the security system, 5) won't help you break the chain of trust, 6) won't help you run Linux.
It was only ever used as part of a commercialy distributed firmware downgrade trick designed for a commercially distributed piracy tool.
Now can we please switch over to a relevant string of hex digits when talking about PS3 security? Please? I suggest "Da" from geohot's keydump, which is the metldr private key, and infinitely more relevant than this 46 DC nonsense.
About as amateur as using a static constant instead of a random number when signing firmware and games, which is exactly what they did (and which pretty much cost them their entire system security).
They wouldn't be any more expensive than the launch PS3, but if that's your benchmark for cost optimization you have bigger issues.
Nintendo doesn't do the whole selling below manufacturing cost thing, and I've seen no indication that they're suddenly going to start doing it.
They aren't. Not for quite a while now. But they used to haemorrhage money, since the original launch PS3 was just about the most pathetically cost-unoptimized product I've ever seen. Stuff inside it: a built-in standalone Ethernet-to-WLAN AP for wireless connectivity (instead of, you know, a WiFi card), an 8-port Gigabit switch with VLAN support, a standalone NAND controller including FTL layer, a 4-port USB 2.0 hub, an IDE-SATA converter chip, a chipset with a die larger than the CPU (because it had a memory controller, video output, PCI Express, multiple support CPUs and a ton of other crap that they don't use), and of course an entire standalone PS2. Not to mention enough BGA chips to make assembly yield specialists cringe. They trimmed some stuff with the later Fat revisions, but until the release of the Slim most of it was still there. The Slim is the first non-WTF PS3 design, as far as cost-optimization.
The PS3 started out with an utterly batshit insane design, then eventually arrived at something roughly resembling what they should've been shipping from day one. The Wii started out with a perfectly reasonable design, then later revisions have been micro-optimizing cost here and there so now they have an incredibly optimized design. I somehow doubt Nintendo is going to go the way of the PS3 for next generation.
"GPU calls"? It'd have to support the entire architecture and register and command set, verbatim, even as far as having the same cycle by cycle performance characteristics if they don't want issues with some games. That is far from "easy". In fact, I'd say it's almost impossible, short of, as you mention, having two GPUs in it. But having two GPUs would be expensive.
Of course nobody expected Linux to be on the Slim (and nobody can complain that they don't have linux on their Slim). I'm just pointing out that removing Linux from the Slim (which in and of itself is fine) is related to removing Linux on the Fat, which isn't. The underlying reason is almost certainly the same, and it's neither (legitimate, i.e. Slim-only) cost saving nor geohot's hack.
It isn't OK, actually. Not because it's illegal or wrong (they have every right to do it), but because they lied about their motive. It that further confirms that they lied about why they removed Linux on the Fats.
They claimed they removed Linux from the Slim due to cost saving reasons, but now we know that Linux "just works" on the Slim because it runs on top of the same hypervisor that GameOS uses. In other words, maintenance cost was implicitly zero due to the way the PS3 works, and they actually had to put more development time into removing Linux than they would've if they'd just left it there. This means that they had a reason to remove Linux a long time ago already.
They lied about why they removed Linux on the Slim, and we don't know their real reason. It follows that they lied about why they removed Linux on the Fat; they were just itching to remove it for the same (unknown) reason they did on the Slim. The Geohot hack was just a poor excuse that they could use.
One possible explanation is that they were planning on removing Linux across all consoles all along to save money in the long term (simply because they wouldn't have to support the tiny launcher in future firmwares - this doesn't save money if you only do it on the Slim, but it does save some money if you do it across all consoles). Or maybe there's an entirely different reason that we don't know about.
People are going to reply that either 1) it was used to break into the console and pirate games/break DRM/hack online games, or 2) it was costly to maintain. Those are what Sony would like you to believe. However, both of those are lies.
It is true that the first remotely notable break in PS3 security occurred through the use of the Linux functionality. This was geohot's original hypervisor exploit. However, that exploit required hardware (a RAM glitching setup), was extremely unreliable, and didn't get you any further than hypervisor access. Nothing ever came out of that hack directly, it was more of an academic thing. This has never had anything to do with piracy and has never been used for piracy.
The next big PS3 hack (which was actually designed for piracy) was a GameOS exploit (PSJailbreak), and later the core of the PS3 security was compromised, with the goal of running Linux, but without depending on any existing Linux functionality (which had been removed by then). So, in fact, OtherOS has never caused security problems from the PS3. In fact, the only thing it clearly did was prevent attack by giving power users a way to run their own code. The vast majority of people who I know participated in developing PS3 hacks (myself included) did so after Sony removed OtherOS, and wouldn't have done so otherwise.
So that takes care about option #1. What about #2? That's what Sony implied when they removed OtherOS from the PS3 Slim (which, remember, happened before any PS3 security issue at all). And we bought it at the time. And then the PS3 security was broken, Slim included, and we found out that GameOS uses the same hypervisor interface as Linux, and that Linux happily ran on the Slim with trivial modification. The truth is that GameOS depends on the same hypervisor as Linux, and OtherOS is nothing but a launcher and a different guest profile in the hypervisor. The amount of code required is insignificant, and the maintenance required just about nonexistent. By maintaining GameOS they are implicitly maintaining OtherOS. High maintenance cost? My ass. This also exculpates geohot's original hack, since that happened after Linux was removed from the Slim, and we now know that the given reason for removing it from the Slim was bullshit.
Then there's the whole selling PS3s at a loss deal, but we all know that Sony is now making a profit on all PS3s, so Linux doesn't hurt there either.
They turned it off because they WANTED to turn it off. The real motive? There clearly is one, but we don't know what it is. The only mildly plausible explanation that I've read is that Sony wanted to push emulated PSN games a la Virtual Console, but studios were concerned about unofficial emulation via Linux. But that's still not terribly convincing.
Note: I was one of the people named in the Sony lawsuit for bringing Linux back on the PS3, so I think I know what I'm talking about.
Try PowerPC 970 . Which isn't exactly identical to the PPC CPU cores in the 360 or the PPU core in the PS3, but it's a reasonable comparison, at least as far as feature set.
The Wii doesn't emulate the Gamecube, it is a Gamecube. Just at a higher clockrate and with more peripherals. To run Gamecube games they turn those off and drop the clock rate.
They can't do that again with the Wii2 because they really need a new GPU now. This little stunt worked because the Gamecube GPU was pretty decent for its time, but if they churn out another console with the same old GX GPU they're going to be the laughingstock of the games industry (no shaders, tiny framebuffer, useless antialiasing modes... won't fly in 2012).
They're going to have a hard time retaining backwards compatibility in a sane manner. The CPU is easy, as long as they stick with PowerPC. But the GPU isn't abstracted out and games talk directly to the hardware. The Wii's GPU hasn't changed since the GameCube (other than clockrate), but this time around they really need a new design with proper modern features like shaders. There are four options: design a new chip that's still backwards compatible, use a new chip and emulate the old in software, keep the old chip around just for backwards compat, and just ditch backwards compatibility.
#1 is unlikely because the Wii's (and Gamecube's) GPU is very divergent compared to modern GPUs, and I somehow doubt AMD will make a complete refresh of that architecture for them, incorporating modern features while retaining 100% backwards compatibility. It'd basically be designing a modern GPU from scratch, and retaining compatibility would be a nightmare. #2 is plausible (heck, I maintain that full Wii emulation on the PS3, a current gen system, is possible), but they're going to have to put a lot of effort into making a near perfect emulator or people are going to complain. #3 is wasteful; this worked for Nintendo in the handheld space where graphics processors weren't exactly overly complex (until the 3DS at least), but I don't see them doing it with a console GPU (Sony did this and we all know how they ended up selling at a loss partly because of it). #4 is eminently possible (and it's not like this is new for Nintendo in the console space - the Gamecube to Wii compatibility was the exception for them, not the rule). I'm going to vote for #4.
And Sony is in a similar situation because, even though the PS3 does have a real OS and dynamic linking, they had the bright idea of linking in the GPU command stream drivers statically into games, so PS3 games are hardcoded to issue NV47 FIFO instructions and good luck getting them to run on any more recent NV architectures.
Imperial is going away in this field. PTH stuff is specified in thousandths of an inch because of the standardized 2.54mm=0.1" pin spacing, and SO-package (and PLCC) surface mount just halved that distance. However, most smaller surface mount packages are specified exclusively in millimeters. I switched my CAD grid from mils (of an inch) to millimeters quite a while ago, because it makes a lot more sense since it increases the chances of your smaller package pins falling on the grid, while you don't really care about the (relatively) huge PTH and SO package pins. Design in imperial makes sense if you're doing old-school PTH kits and you want everything on a nice 0.1" grid, but not otherwise.
If you take a projector, be it dots or multimedia, and a camera right on top of it, the projection as seen by the camera will be exactly the same size within the camera's field of view regardless of how far away the wall is. If you move the wall back, the projection increases in size at the wall, but the wall (with the projection) decreases in size as seen from the fixed camera. The two effects cancel out.
The simple trig will give you the nominal separation at the surface. Then, when you run the trig in reverse to calculate the pixel separation at the camera... you end up with exactly the same reparation regardless of depth. The camera has a radial field of view just like the projector, and pixels correspond to a fixed angle. Since the camera and the projector are on the same plane, it cancels out. Ignoring brightness (which is unreliable) and dot size (which isn't accurate enough), a flat far surface looks exactly the same as a near flat surface, except one will be horizontally shifted as a whole when compared to the other.
Many people make this mistake, probably because they're imagining the pattern from a steep angle when viewed from outside the Kinect (or have seen YouTube videos to that effect). Our brains are also very good at associating the same angular (pixel) separation on an object that is (apparently) far away with a larger actual separation (this is why those optical illusions where two objects look different in size due to false depth cues work). However, when you view the pattern from the Kinect on the same plane as the source, and ignoring any previous knowledge of how deep parts of the image are (since, of course, finding out is the whole point), the average separation between dots is the same across the entire depth range where local depth difference is zero. Separation between dots is proportional to the derivative of the depth (local depth difference) only, but it is not proportional to absolute depth.
For example, look at this IR dot image, as seen by the Kinect (note: half resolution, since getting the fullres raw image out via USB is problematic). If you look closely and ignore the varying dot brightness and dot size (the dots are laser beams so the virtual point source for each beam is very far behind the Kinect, and thus isn't on the same plane as the camera so dot size varies as seen by it), you'll see that the dot density is basically the same across all depths (measured in dots per area, not dot pixels per area - don't be misled by the larger dots on surfaces near the camera).
It sees horizontal dot displacement... as compared to an internal calibration reference image. There's an internally stored reference image (either as an actual image, a set of dot coordinates, or perhaps just a calibration matrix if the dot pattern is fully predictable - we don't know specifically how it's stored). If you watch a video of the IR dot image it's very easy to see how the dots move left and right as objects move near and far, but there's no way to tell the precise depth of a point in the image without a reference image to compare to.
Displacement is distance, but (distance|displacement) between different dots in the captured image isn't the same as (distance|displacement) between a dot and its counterpart in a reference image.
Put another way, the Kinect sees almost the same image when it looks at a wall 1m from it and a wall 5m from it (other than brightness, but that also isn't part of the algorithm because it varies depending on the material). The only difference is that one is horizontally shifted from the other. It is this absolute shift (which is compared against an internal calibration image) that is used to calculate depth. Without the reference image and the absolute comparison there would be no practical way to obtain an absolute depth measurement from an image like that.
Yes, dot distance does correspond to the slope of the depth, but then you'd have to integrate the resulting measurements to measure depth (that, and the dot field isn't a pattern, it's pseudorandom, so there's no trivial way to know how far apart dots are supposed to be in the first place). This isn't what the Kinect does; it directly correlates dot clusters to a reference image and measures absolute displacement against it.
Not the distance between dots. The camera sees exactly the same dot density regardless of depth because the projector and the camera are on the same plane (it doesn't matter if the surface is near or far, since dots will have the same angular distance when viewed from the camera). What it does measure is horizontal displacement vs. a reference image. This works because the camera and the projector are horizontally offset.
PrimeSense developed the sensor technology (hardware and firmware) that gives you a depth image. Microsoft took that depth image and created the algorithms that perform body tracking (software).
PrimeSense also have their own body tracking solution (they call it NITE), but it's based on an entirely difference concept and requires a calibration pose to "lock in" initially. Microsoft doesn't use NITE.
This has nothing to do with reconstructing a depth image from a 2D image. The Kinect is a depth camera and already gives you a real depth image (not a guess).
It's not the key that lets you sign your own code. It's not the key that lets you decrypt the OS. It's not the key that lets you decrypt games. It doesn't let you do anything interesting. Huh? What? Yes, you heard me.
It's a useless key that is used to authenticate factory service dongles (which will only let you run signed executables anyway, and those signing keys are secure as of the latest firmware and will never be obtained). Its only purpose so far was to perform downgrades (as released in a commercial product using stolen service executables) in order to use another commercial product (by ostensibly the same company) which used an exploit to enable game piracy (using a whole bunch of other methods unrelated to it). All of this predated the 27c3 presentation and geohot's release. It's useless now and has never served any "master" key purpose. It was called the "master key used to generate service dongle keys", then of course the clueless news websites just shortened that to "master key".
The PS3 has tons of keys and you can't "do everything" with one key. You need three or four to run stuff via metldr, that's why geohot released a whole bunch of keys, not just one (none of which are the one that was used here). But if you must pick one "representative" key to obfuscate and post and distribute and make an icon out of, at least pick Da from geohot's keyset (starts with C5). That's the metldr private key, originally stored at some vault at Sony's HQ, calculated thanks to their massive signing screwup, and which can be used to sign code that all existing PS3s will execute, forever (you still need to encrypt it, but signing is ideologically more important). And for fuck's sake, please let go of the "46 DC" dongle key already. Please.
And using a SPI interface to control it is like using Lego as a drive train from the V8 to the rest of the car.
But, you see, anything with Arduino in the name is instamagically popular. As stupid as using an Arduino is, this project has a much bigger chance of success as an Arduino shield than as a standalone board.
I'm too lazy to check, but I'm willing to bet there are Arduino shields out there that only use the Arduino for power.