NAT needs a connection state tracker to work anyway (which forms the basis of a stateful firewall). Slap a stateful firewall on v6, no need for actual NAT, and you get better security without the drawbacks. As for dynamic IPs, every IPv6 customer gets at least 18,446,744,073,709,551,615 IPv6s to himself. It's pretty easy to make computers pick one at random. This alone makes IPv6 a lot more resistant to attack than IPv4, since IP netblock scanning becomes all but impossible.
It's a disassembler database, which by its very nature contains a complete memory image of the hypervisor as well as annotations and metadata. He also has a bunch of bare binaries lying around the.rar archive next to the databases per se.
There's a difference between sticking to your beliefs and promises and being completely careless. I'm not saying he shouldn't have released it, I'm saying releasing it first without even giving himself the chance to talk to a lawyer to understand the consequences is stupid. He acted without giving himself time to become informed about what might happen. Really, it's common sense: if you find yourself in a legal mess, you lawyer up first, then you decide how you want to approach the issue. Getting a lawyer doesn't give sony any more time. What not getting a lawyer does is significantly decrease the chances of a positive outcome for you (sad, but true), unless you're a legal expert yourself.
Well, his.rar file contains verbatim copies of a bunch of chunks of Sony's firmware, including the hypervisor and SPU code. It doesn't mean he'll necessarily get any legal flak for it, but it's an incredibly dumb move, especially because, as far as I can tell, it's the first clearly legally troublesome thing that he's done. AFAIK, until now he hadn't distributed any Sony copyrighted material, just his own documentation and open source code.
Okay, to be fair, I just found out that Kotaku reports getting confirmation from SCEE. I don't exactly consider kotaku (or SCEE for that matter) to be completely infallible, but at least this beats blog comments.
Nonetheless, I still think this makes no sense, if it did actually take place. If it did, graf_chokolo's reaction is, to put it bluntly, stupid (at the very least, his database, which by its nature contains a full copy of the hypervisor, is copyright infringement if nothing else). Bad plan if you are in fact the target of legal action. He needs a lawyer ASAP.
This is the entirety of the original source material for this story:
Guys, do not contact me anymore because SONY got me. They have all my stuff and accounts now, so be careful.
It was not a troll guys, it’s me, they really got me, it was a matter of time. So be careful now, i warned you.
Guys, SONY was today at my home with police and got all my stuff and accounts. So be careful from now on.
Guys, i don’t joke, it’s serious. And to prove it, i kept my word and uploaded all my HV reversing stuff. Upload it everywhere so SONY couldn’t remove it easily. Grab it guys, it contains lots of knowledge about HV and HV procs.
Here is my HV bible:...
"SONY was today at my home"? That's not how raids work. In the US, Sony had to go through some rather extensive legal action to be able to get a TRO on geohot, and now they've convinced the German police to raid some random hacker's house out of nowhere? He's also not even one of the more prominent people involved, and had very little to do both with the core hacks and with subsequent piracy tools - he mostly worked on his own on hypervisor reverse engineering and there's just about nothing they could charge him with. This would also be the first action taken by SCEE regarding this entire issue. And you'd expect someone other than graf_chokolo to notice, publish, or somehow independently report the raid. Not to mention that if you're raided, the first thing you do is talk to an attorney, not post a care package online (as "proof"?). None of this makes any sense.
He did mention that if he ever got a takedown notice from Sony or something along those lines, he'd release his hypervisor disassembler database. I think it's more likely that he got tired of waiting and just made up an excuse.
As far as I can tell, he's just projecting the depth (as a few color bands) on top of the table. About five lines of Python with libfreenect and OpenCV. He isn't even tracking anything, just projecting the raw depth quantized to a few layers and roughly calibrated onto the table. Seriously, there are probably hundreds of Kinect hacks more impressive than this one.
The only odd part about this Kinect hack is that he's using the ugly proprietary CodeLabs NUI drivers instead of OpenKinect/libfreenect or OpenNI/SensorKinect.
They didn't pull OtherOS in response to the security break, they pulled OtherOS because they were itching for a half-assed excuse to do it. What made it obvious is the fact that OtherOS would've just run on the Slim automagically had they not put in extra effort to disable it. Since they explicitly disabled it (costing them money to develop the changes to disable it on the Slim), that means they had a reason well ahead of geohot's break. They made it seem like OtherOS on the Slim would've cost them extra money to maintain, but it turned out to be the exact opposite, so they were trying to hide the real reason why they removed it. What the reason was is anyone's guess, but there clearly is one and it's not an academic hilariously unstable hardware-based glitching attack.
Apparently it only works at very specific quality settings. Re-saving with GIMP, I can see the message at quality 24, 38, 41 (barely), 43, 60, 65 (barely), 69 (barely), 72 (barely), and a few others even less.
As far as I can tell (I haven't read the paper), it works by setting up a static hard to compress pattern, and then slightly altering that pattern in certain macroblocks so that they just push the boundary into a different kind of compression artifact at certain quality/quantizer levels. So the entire image is compressed one way at one quality, a different way at another quality, and at the threshold between them there's a quality level where the message blocks compress differently and you can see them.
Also, recompressing has a high chance of destroying the effect permanently. For example, saving at quality 51 destroys the message, and re-compressing at any quality level no longer makes it visible.
Sony didn't remove Other OS in response. They made it seem like that. In reality, they were just itching to get an excuse to remove it.
The proof? Sony stated that they discontinued support for Other OS on the PS3 Slim because they weren't interested in working to supporting that feature, but they lied. As it turns out, Other OS would've worked just fine on the Slim had they not removed it (which actually took more effort than just leaving it be). The only conclusion is that they wanted Other OS gone for some other reason (there were no hacks back then, so security wasn't an excuse), and that reason would logically apply to older PS3s too. Some speculate that the reason was that Sony wanted to kill off emulators running on Linux in order to push PSN-based "virtual console" games. This, by the way (lack of Other OS on the slim) is why Geohot started his efforts to break the system.
Remember, Sony made sure to kill off the use of PS3s as part of research clusters by discontinuing OtherOS-capable models with a false excuse and later pulling the feature outright on even refurbished older units with current firmware.
They don't give a damn about research, they just pretend they do to get free advertising and public karma.
A dark adapted pupil is 9mm in diameter, so an 8mm beam at 3 miles is just as dangerous as a 1mm beam at 10 centimeters. 100mW is well past the retinal damage threshold. Laser beams don't lose power with distance (in clear weather), they just expand. Until they expand to a diameter wider than a human pupil (such that the amount of power that can enter the eye at once actually drops), they're equally dangerous.
However, your 8mm figure is way off as far as I can tell. A typical laser pointer has a divergence of 1mRad or so. That's one meter at one kilometer (tan(x radians) is basically x for low values of x, so you can just say 1mRad = 0.001 width per distance). If I didn't mess up my math, that's about 8 microwatts entering the eye at one kilometer (from a 100mW pointer). Definitely visible, possibly annoying, but completely safe.
It's called -ffunction-sections, which puts each function in a file in its own section so the linker can get rid of all the unused ones. No need for LTO.
Expanded to 20cm, the power level is over 100 times lower, so it's pretty much guaranteed to be safe. I also typoed the "I'm going going to try pointing it into my eye". I meant "I'm not going to try pointing it into my eye", of course.
To throw some numbers in: The glasses that the GP linked to are OD 4 for 532nm light (i.e. green Nd:YAG lasers, which are basically guaranteed to be the type used by this weapon). That means they block 99.99% of the beam at that wavelength. That's quickly going to turn any beam designed to be borderline non-permanently-damaging into barely a bother.
In fact, I just ran a quick test. I have a 30mW green pointer, which is definitely unsafe for direct eye exposure. I expanded the beam with a lens to about a 20cm radius, which is eye-safe at this power level. Looked at it thought my glasses (I actually have that same model), and it was just a very slight orange glow, about on par with an indicator LED. Took the goggles off and it was very annoying (I had an afterimage for a few minutes). I imagine the laser weapon will be closer to the damage threshold than my quick test, but still, the glasses will totally destroy any effect unless the laser runs at power levels much higher than eye-safe ones.
Or, testing with the (definitely eye unsafe) collimated 30mW, through the glasses, onto a wall: the green dot is barely visible. I'm going going to try pointing it into my eye (see below), but that mount of light is not going to bother anyone.
Note for anyone wanting to try this: don't unless you really know what you're doing. In particular, looking into the bare beam with glasses on is a very bad idea. You probably won't damage your eyes with the green light, but these cheap chinese pointers tend to lack IR filters, and that can screw you since the glasses won't block IR (worse, your blink response won't trigger and you'll slowly cook your retina). In fact, I can see a slight deep red glow around the projected green dot going through the glasses, which indicates there's a considerable amount of leaked IR, probably well above the damage threshold (if you can see IR, there's a lot of it).
The 360 has extremely well designed security, and the only exploits that there have been for it were quite contrived and difficult to pull off (and easily fixed). It's a great design.
However, it does fail in the drive security department, which is why there's all the warez firmware hacking going on. But the core system is very secure.
Hardware acceleration has been enabled ever since AsbestOS came out, and this also applies to native-boot AsbestOS. Of course, a driver needs to be written/ported. Getting nouveau integrated into the lv1 graphics framework is somewhere on my TODO for 2011.
We published our exploits at the talk by explaining exactly how they works, and how anyone could use them. We said we'd release tools through the following month, and we already released two Git repositories containing most of the tools (that's 4 days after the talk). We didn't release keys due to fear of legal repercussions, but we told people exactly how to calculate them, and they did.
Geohot first released a useless signed loader to prove that he had the keys. Then he released the keys. He hasn't released information on how he got the metldr plaintext and apparently doesn't have plans to do so.
Personally, I think explaining things first, then a few days later releasing tools, is better than just dumping keys on the world and keeping how you got them a secret.
We (fail0verflow) discovered and released two things:
An exploit in the revocation list parsing, enabling us to dump a bunch of loaders, and thus their decryption keys
A humongous screwup by Sony, enabling us to calculate their private signing keys for all of those loaders, and thus sign anything to be loaded by those loaders
We used these techniques to obtain encryption, public, and private keys for lv2ldr, isoldr, the spp verifier, the pkg verifier, and the revocation lists themselves. We could've obtained appldr, (the loader used to load games and apps), but chose not to, since we are not interested in app-level stuff and that just helps piracy. We didn't have lv1ldr, but due to the way lv1 works, we could gain control of it early in the boot process through isoldr, so effectively we also had lv1 control.
With these keys we could decrypt firmware and sign our own firmware. And since the revocation is useless and the lame "anti-downgrade" protection is also easily bypassed, this already enables hardware-based hacks and downgrades forever. Basically, homebrew/Linux on every currently manufactured PS3, through software means now, and through hardware means (flasher/modchip) forever, regardless of what Sony tries to do with future firmwares.
The root of all of the aforementioned loaders is metldr, which remained elusive. Then Geohot announced that he had broken into metldr (with an exploit, analogous to the way we exploited lv2ldr to get its keys) and was thus able to apply our techniques one level higher in the loader chain. He has released the metldr keyset (with the private key calculated using our attack), but not the exploit method that he used.
The metldr key does break the console's security even more (especially with respect to newer, future firmwares - and thus also piracy of newer games), and also makes some things require less workarounds. Geohot clearly did a good job finding an exploit in it, but considering a) he used our key recovery attack verbatim, and b) he found his exploit right after our talk, so he was clearly inspired by something we said when we explained ours, I think we deserve a little more credit than we're getting for this latest bit of news.
There's still bootldr and lv0, which are used at the earliest point during the PS3 boot process. These remain secure, but likely mean little for the PS3 security at this stage.
Sad but true. No matter what the law says, getting protected as mere users is near impossible. Unless you're willing to go through a costly legal battle, no one cares.
A few days ago we presented ourselves as a hacker group at the 27th Chaos Communication Congress, presenting PS3 hacks, and now we have a YouTube account squater/scammer asking for donations in our name. I've tried YouTube impersonation reports, but apparently I'm "providing insufficient information" (duh, you get 300 characters to explain everything). I've tried YouTube Legal, received no response so far. I've tried getting people to flag the videos as a scam, but that doesn't work. I'm not even going to try PayPal; I've dealt with them before and they don't care.
This whole thing reminds me of my run-ins with scammers back when I was actively developing Wii homebrew stuff. The payment processors (ClickBank, Plimus, PayPal, and co.) don't care. They'll happily take people's money and hand it over to scammers, keeping a percentage, of course, even if what is being sold is a scam or illegal.
If you're a small consumer or producer, companies don't give a rat's ass about you. They'll only listen if they know you have the power and lawyers to actually file a lawsuit and win.
Everyone keeps forgetting that OtherOS was already removed / discontinued on new PS3s - the Slim - before Geohot started his work. That's what started it all. Removing OtherOS on the Fat made it a lot worse, of course, but it's the lack of OtherOS on the Slim (for a fishy - and, as it turned out, totally BS reason) that got people looking initially. We even gave it a quick look exactly one year ago, at 26c3, though we didn't try very hard (this was before OtherOS was pulled from the Fat).
Honestly, it's perfectly possible to engineer the signature randomization failure deliberately (it would certainly be very easy to botch a signer like this and make it look like a bug, see the Underhanded C Contest for similar examples), but I think it's extremely unlikely that something like this actually happened. Never attribute to malice that which can be adequately explained by stupidity. Especially considering the rest of the security is messed up in ways that clearly indicate they just didn't know what they were doing.
NAT needs a connection state tracker to work anyway (which forms the basis of a stateful firewall). Slap a stateful firewall on v6, no need for actual NAT, and you get better security without the drawbacks. As for dynamic IPs, every IPv6 customer gets at least 18,446,744,073,709,551,615 IPv6s to himself. It's pretty easy to make computers pick one at random. This alone makes IPv6 a lot more resistant to attack than IPv4, since IP netblock scanning becomes all but impossible.
The WNDR3700's default firmware is based on OpenWRT and Netgear (apparently) still managed to botch IPv6.
Personally, I run my own OpenWRT build on mine and that works great, providing a he.net v6 tunnel for my entire LAN.
It's a disassembler database, which by its very nature contains a complete memory image of the hypervisor as well as annotations and metadata. He also has a bunch of bare binaries lying around the .rar archive next to the databases per se.
There's a difference between sticking to your beliefs and promises and being completely careless. I'm not saying he shouldn't have released it, I'm saying releasing it first without even giving himself the chance to talk to a lawyer to understand the consequences is stupid. He acted without giving himself time to become informed about what might happen. Really, it's common sense: if you find yourself in a legal mess, you lawyer up first, then you decide how you want to approach the issue. Getting a lawyer doesn't give sony any more time. What not getting a lawyer does is significantly decrease the chances of a positive outcome for you (sad, but true), unless you're a legal expert yourself.
Well, his .rar file contains verbatim copies of a bunch of chunks of Sony's firmware, including the hypervisor and SPU code. It doesn't mean he'll necessarily get any legal flak for it, but it's an incredibly dumb move, especially because, as far as I can tell, it's the first clearly legally troublesome thing that he's done. AFAIK, until now he hadn't distributed any Sony copyrighted material, just his own documentation and open source code.
Okay, to be fair, I just found out that Kotaku reports getting confirmation from SCEE. I don't exactly consider kotaku (or SCEE for that matter) to be completely infallible, but at least this beats blog comments.
Nonetheless, I still think this makes no sense, if it did actually take place. If it did, graf_chokolo's reaction is, to put it bluntly, stupid (at the very least, his database, which by its nature contains a full copy of the hypervisor, is copyright infringement if nothing else). Bad plan if you are in fact the target of legal action. He needs a lawyer ASAP.
This is the entirety of the original source material for this story:
"SONY was today at my home"? That's not how raids work. In the US, Sony had to go through some rather extensive legal action to be able to get a TRO on geohot, and now they've convinced the German police to raid some random hacker's house out of nowhere? He's also not even one of the more prominent people involved, and had very little to do both with the core hacks and with subsequent piracy tools - he mostly worked on his own on hypervisor reverse engineering and there's just about nothing they could charge him with. This would also be the first action taken by SCEE regarding this entire issue. And you'd expect someone other than graf_chokolo to notice, publish, or somehow independently report the raid. Not to mention that if you're raided, the first thing you do is talk to an attorney, not post a care package online (as "proof"?). None of this makes any sense.
He did mention that if he ever got a takedown notice from Sony or something along those lines, he'd release his hypervisor disassembler database. I think it's more likely that he got tired of waiting and just made up an excuse.
As far as I can tell, he's just projecting the depth (as a few color bands) on top of the table. About five lines of Python with libfreenect and OpenCV. He isn't even tracking anything, just projecting the raw depth quantized to a few layers and roughly calibrated onto the table. Seriously, there are probably hundreds of Kinect hacks more impressive than this one.
The only odd part about this Kinect hack is that he's using the ugly proprietary CodeLabs NUI drivers instead of OpenKinect/libfreenect or OpenNI/SensorKinect.
They didn't pull OtherOS in response to the security break, they pulled OtherOS because they were itching for a half-assed excuse to do it. What made it obvious is the fact that OtherOS would've just run on the Slim automagically had they not put in extra effort to disable it. Since they explicitly disabled it (costing them money to develop the changes to disable it on the Slim), that means they had a reason well ahead of geohot's break. They made it seem like OtherOS on the Slim would've cost them extra money to maintain, but it turned out to be the exact opposite, so they were trying to hide the real reason why they removed it. What the reason was is anyone's guess, but there clearly is one and it's not an academic hilariously unstable hardware-based glitching attack.
Apparently it only works at very specific quality settings. Re-saving with GIMP, I can see the message at quality 24, 38, 41 (barely), 43, 60, 65 (barely), 69 (barely), 72 (barely), and a few others even less.
As far as I can tell (I haven't read the paper), it works by setting up a static hard to compress pattern, and then slightly altering that pattern in certain macroblocks so that they just push the boundary into a different kind of compression artifact at certain quality/quantizer levels. So the entire image is compressed one way at one quality, a different way at another quality, and at the threshold between them there's a quality level where the message blocks compress differently and you can see them.
Also, recompressing has a high chance of destroying the effect permanently. For example, saving at quality 51 destroys the message, and re-compressing at any quality level no longer makes it visible.
Sony didn't remove Other OS in response. They made it seem like that. In reality, they were just itching to get an excuse to remove it.
The proof? Sony stated that they discontinued support for Other OS on the PS3 Slim because they weren't interested in working to supporting that feature, but they lied. As it turns out, Other OS would've worked just fine on the Slim had they not removed it (which actually took more effort than just leaving it be). The only conclusion is that they wanted Other OS gone for some other reason (there were no hacks back then, so security wasn't an excuse), and that reason would logically apply to older PS3s too. Some speculate that the reason was that Sony wanted to kill off emulators running on Linux in order to push PSN-based "virtual console" games. This, by the way (lack of Other OS on the slim) is why Geohot started his efforts to break the system.
Remember, Sony made sure to kill off the use of PS3s as part of research clusters by discontinuing OtherOS-capable models with a false excuse and later pulling the feature outright on even refurbished older units with current firmware.
They don't give a damn about research, they just pretend they do to get free advertising and public karma.
A dark adapted pupil is 9mm in diameter, so an 8mm beam at 3 miles is just as dangerous as a 1mm beam at 10 centimeters. 100mW is well past the retinal damage threshold. Laser beams don't lose power with distance (in clear weather), they just expand. Until they expand to a diameter wider than a human pupil (such that the amount of power that can enter the eye at once actually drops), they're equally dangerous.
However, your 8mm figure is way off as far as I can tell. A typical laser pointer has a divergence of 1mRad or so. That's one meter at one kilometer (tan(x radians) is basically x for low values of x, so you can just say 1mRad = 0.001 width per distance). If I didn't mess up my math, that's about 8 microwatts entering the eye at one kilometer (from a 100mW pointer). Definitely visible, possibly annoying, but completely safe.
It's called -ffunction-sections, which puts each function in a file in its own section so the linker can get rid of all the unused ones. No need for LTO.
Expanded to 20cm, the power level is over 100 times lower, so it's pretty much guaranteed to be safe. I also typoed the "I'm going going to try pointing it into my eye". I meant "I'm not going to try pointing it into my eye", of course.
To throw some numbers in: The glasses that the GP linked to are OD 4 for 532nm light (i.e. green Nd:YAG lasers, which are basically guaranteed to be the type used by this weapon). That means they block 99.99% of the beam at that wavelength. That's quickly going to turn any beam designed to be borderline non-permanently-damaging into barely a bother.
In fact, I just ran a quick test. I have a 30mW green pointer, which is definitely unsafe for direct eye exposure. I expanded the beam with a lens to about a 20cm radius, which is eye-safe at this power level. Looked at it thought my glasses (I actually have that same model), and it was just a very slight orange glow, about on par with an indicator LED. Took the goggles off and it was very annoying (I had an afterimage for a few minutes). I imagine the laser weapon will be closer to the damage threshold than my quick test, but still, the glasses will totally destroy any effect unless the laser runs at power levels much higher than eye-safe ones.
Or, testing with the (definitely eye unsafe) collimated 30mW, through the glasses, onto a wall: the green dot is barely visible. I'm going going to try pointing it into my eye (see below), but that mount of light is not going to bother anyone.
Note for anyone wanting to try this: don't unless you really know what you're doing. In particular, looking into the bare beam with glasses on is a very bad idea. You probably won't damage your eyes with the green light, but these cheap chinese pointers tend to lack IR filters, and that can screw you since the glasses won't block IR (worse, your blink response won't trigger and you'll slowly cook your retina). In fact, I can see a slight deep red glow around the projected green dot going through the glasses, which indicates there's a considerable amount of leaked IR, probably well above the damage threshold (if you can see IR, there's a lot of it).
Yes, but homebrew on the stock OS is something Sony is going to try to fight anyway. We're more interested in the (unpatchable) low level boot hacks.
The 360 has extremely well designed security, and the only exploits that there have been for it were quite contrived and difficult to pull off (and easily fixed). It's a great design.
However, it does fail in the drive security department, which is why there's all the warez firmware hacking going on. But the core system is very secure.
Hardware acceleration has been enabled ever since AsbestOS came out, and this also applies to native-boot AsbestOS. Of course, a driver needs to be written/ported. Getting nouveau integrated into the lv1 graphics framework is somewhere on my TODO for 2011.
We published our exploits at the talk by explaining exactly how they works, and how anyone could use them. We said we'd release tools through the following month, and we already released two Git repositories containing most of the tools (that's 4 days after the talk). We didn't release keys due to fear of legal repercussions, but we told people exactly how to calculate them, and they did.
Geohot first released a useless signed loader to prove that he had the keys. Then he released the keys. He hasn't released information on how he got the metldr plaintext and apparently doesn't have plans to do so.
Personally, I think explaining things first, then a few days later releasing tools, is better than just dumping keys on the world and keeping how you got them a secret.
We (fail0verflow) discovered and released two things:
We used these techniques to obtain encryption, public, and private keys for lv2ldr, isoldr, the spp verifier, the pkg verifier, and the revocation lists themselves. We could've obtained appldr, (the loader used to load games and apps), but chose not to, since we are not interested in app-level stuff and that just helps piracy. We didn't have lv1ldr, but due to the way lv1 works, we could gain control of it early in the boot process through isoldr, so effectively we also had lv1 control.
With these keys we could decrypt firmware and sign our own firmware. And since the revocation is useless and the lame "anti-downgrade" protection is also easily bypassed, this already enables hardware-based hacks and downgrades forever. Basically, homebrew/Linux on every currently manufactured PS3, through software means now, and through hardware means (flasher/modchip) forever, regardless of what Sony tries to do with future firmwares.
The root of all of the aforementioned loaders is metldr, which remained elusive. Then Geohot announced that he had broken into metldr (with an exploit, analogous to the way we exploited lv2ldr to get its keys) and was thus able to apply our techniques one level higher in the loader chain. He has released the metldr keyset (with the private key calculated using our attack), but not the exploit method that he used.
The metldr key does break the console's security even more (especially with respect to newer, future firmwares - and thus also piracy of newer games), and also makes some things require less workarounds. Geohot clearly did a good job finding an exploit in it, but considering a) he used our key recovery attack verbatim, and b) he found his exploit right after our talk, so he was clearly inspired by something we said when we explained ours, I think we deserve a little more credit than we're getting for this latest bit of news.
There's still bootldr and lv0, which are used at the earliest point during the PS3 boot process. These remain secure, but likely mean little for the PS3 security at this stage.
For the record, that wasn't there initially. We had to complain to him to get him to add that.
Sad but true. No matter what the law says, getting protected as mere users is near impossible. Unless you're willing to go through a costly legal battle, no one cares.
A few days ago we presented ourselves as a hacker group at the 27th Chaos Communication Congress, presenting PS3 hacks, and now we have a YouTube account squater/scammer asking for donations in our name. I've tried YouTube impersonation reports, but apparently I'm "providing insufficient information" (duh, you get 300 characters to explain everything). I've tried YouTube Legal, received no response so far. I've tried getting people to flag the videos as a scam, but that doesn't work. I'm not even going to try PayPal; I've dealt with them before and they don't care.
This whole thing reminds me of my run-ins with scammers back when I was actively developing Wii homebrew stuff. The payment processors (ClickBank, Plimus, PayPal, and co.) don't care. They'll happily take people's money and hand it over to scammers, keeping a percentage, of course, even if what is being sold is a scam or illegal.
If you're a small consumer or producer, companies don't give a rat's ass about you. They'll only listen if they know you have the power and lawyers to actually file a lawsuit and win.
Everyone keeps forgetting that OtherOS was already removed / discontinued on new PS3s - the Slim - before Geohot started his work. That's what started it all. Removing OtherOS on the Fat made it a lot worse, of course, but it's the lack of OtherOS on the Slim (for a fishy - and, as it turned out, totally BS reason) that got people looking initially. We even gave it a quick look exactly one year ago, at 26c3, though we didn't try very hard (this was before OtherOS was pulled from the Fat).
Honestly, it's perfectly possible to engineer the signature randomization failure deliberately (it would certainly be very easy to botch a signer like this and make it look like a bug, see the Underhanded C Contest for similar examples), but I think it's extremely unlikely that something like this actually happened. Never attribute to malice that which can be adequately explained by stupidity. Especially considering the rest of the security is messed up in ways that clearly indicate they just didn't know what they were doing.