These ridiculous claims remind me of that "tapionvslink" guy who swears that the Wii has a GPGPU with programmable shaders and twice the RAM and all sorts of things that the homebrew community knows are bullshit, just because he did some broken math on die sizes. He still maintains that we're all ignorant and just haven't figured out what real Wii games are doing with the GPU. Riiight.
Seriously, if the iPad were PowerPC, don't you think we'd know by now, considering it's been jailbroken? Chipworks also tore down the chip and found nothing unusual; it's just another mobile ARM. Also, no one in their right mind would ever use a CPU emulator on a mobile platform OS. It's one of the best ways to completely nuke your battery life, not to mention performance. It's a cute theory, but it's so thoroughly impossible it's not even funny.
One of the many exploits that we've used to own the Wii (in fact, the very first runtime IOS exploit that we used, which I found and implemented) was a NULL pointer dereference bug, and it wasn't even a function pointer.
I wrote a detailed blog post about it recently. The short version is that they doubly dereference a near-NULL address and write to it, and NULL happens to be real physical memory that we control (call it 'insecure', if you wil). The double dereference lets us direct the write anywhere, including the stack, and it's game over. That's the "usermode" exploit. Privilege escalation into the kernel is trivial because they have some huge kernel holes. The fact that they map the 'insecure' memory as executable (!) in every application makes it even easier.
I'm tired of people shoehorning the power-hungry x86 architecture into small devices. If there's one thing that Apple did right it's not using the Atom. The WePad runs Linux: there's no reason to stick with the legacy x86 architecture. Even Adobe Flash works on ARM (just not Flash 10 yet).
If the WePad used an ARM chip, it could probably retain its feature set and bump up the battery duration to the iPad level, which seems to be the only feature where it loses to it.
Just do what I do. I use relatively strong passwords. On places which require password replacement, I just append an ever-incrementing number, while still keeping the strong password part. This effectively bypasses the aging and lets you keep using the same password (a single incrementing number should be easy to remember, and you can always try a few times).
I've never been able to play fullscreen SD content, much less HD content, with Flash under Linux. x86_64, latest adobe labs 64bit player. At least not without the video skipping two out of three frames and generally bogging down the entire windowing system. And don't even think about using apps that perform any processing on the video (YouTube 3D? Hope you like your 4fps windowed, 2fps fullscreen).
I'm still waiting for the magical how-to-make-Flash-not-suck guide from the people who claim that Flash does indeed work OK. Until then, I'm sticking to mplayer -fs/tmp/Flash* to play fullscreen YouTube videos.
If the tools and know how are already there, it seems kind of illogical to throw that all away and start from scratch.
By that token, if homebrew hackers and piracy hackers were about on the same level, we should see about half of all consoles get hacked for piracy and then homebrew, and half get hacked for homebrew and then piracy. In fact, what we have seen is the latter in every case since the PS2, except for the only console where homebrew already existed in some officially supported form.
Well... by this logic then we can say Homebrew hackers suck at it as well, since I can produce for you lots of actions, code and consequences of poorly programmed homebrew as well.
There's a distinction between the people providing the hacks (code execution entry points for homebrew, game loading patches / modules for piracy, as well as the low-level hardware reverse engineering and frameworks) and the people using them (people who write homebrew apps, or people who write / modify game loaders that rely on those patches). Arguably the former need to be more skilled hackers than the latter, as you need knowledge of the system architecture, not just knowledge of an API and generic programming. Of course there's a lot of crap built on top of homebrew libs and piracy tools alike. What I'm saying is that the people responsible for homebrew, in my experience with the Wii, write much better code than the people responsible for piracy. In fact, I'm willing to say that the "core" people responsible for piracy are worse coders than many homebrew application coders. For example, there are some homebrew tools that perform some benign system modifications, and these have (some) proper safety checks, while the tools written by the piracy guys don't.
This reminds me of another benchmark: the contribution to homebrew libs (used for regular homebrew and piracy tools alike) by the guy responsible for most of the piracy tools amounts to precisely one trivial patch which added support for reading a few extra system settings (that I hadn't bothered to implement back when I wrote the original system setting code). Take that however you want, I'm just putting it out as an example of just how insignificantly little piracy has contributed to homebrew.
"Not as good as X" and "Everyone Y Sucks!" are two entirely different positions. As a group, I would say your statement above is true, but that is very different from saying all pro-piracy advocates are crappy hackers.
I never said that all pro-piracy console hackers are idiots. I'm saying that the vast majority of pro-piracy Wii hackers are idiots (which I know because I spent two years working with the Wii), and that is is my impression that, in general, pro-piracy hackers tend not to be as good as pro-homebrew hackers and, therefore, tend to rely and depend upon the latter to kickstart piracy on a console. This is a conclusion that I draw from the available data (Wii plus the general statistic as seen in the table above), as well as comments by other console hackers. I only make a strong statement that Wii piracy hackers suck, not that all piracy console hackers suck.
However, I would counter with the fact that piracy is, generally by it's very definition, a dangerous "occupation." I would not expect the piracy aspect of consoles to be as safe, sane or elegant as other forms of programming. Piracy, like it's sea going legacy, is a dirty business... expecting it to be clean or judging piracy against the standards of the Navy is a bit like comparing apples to oranges.
That's one way to see it. The way I see it is that piracy isn't inherently dangerous, or at least not any more so than homebrew. Instead, the danger is caused by the generally low quality of piracy tools, as a consequence of the lesser skill of the people producing them. Homebrew entry points and exploits aren't exactly the cleanest code ever, bu
Chances are the OS is going to be exactly the same, and you can tweak a plist file on a jailbroken phone to enable multitasking on older devices. You can easily make a 3G think it's a 3GS. The feature will be there, just disabled.
No it doesn't, unless the apps are crap. The real problem is RAM, not CPU. On a 3G, you can run 5-7 lightweight apps with ease, but you can barely run 2 heavyweight apps at once. The symptom is that it runs out of RAM, freezes for a short while, then kills one of the apps.
For example, right now, I just backgrounded Messages, Photos, Notes, Weather, Clock, Calculator, and Voice Memos. That worked fine; those are very lightweight. Then I opened Twitterific, which is starting to push things. Nothing got killed yet though. Then I opened Maps, and that pushed it over the edge; Clock and Notes got killed. Then I opened YouTube and hit a video, and that nuked Calculator and Voice Memos, plus YouTube itself refused to background and got killed as I hit home. Then I opened iPod to listen to some music, which worked fine thanks to the defunct YouTube. But once you open Cydia, abandon all hope; everything but iPod gets killed.
Some of the amazing things they have come up with to make the Wii do things it was never intended to do are exceptionally impressive.
Those things were developed for homebrew and legitimate modding, then duct-taped together to enable piracy.
Not a single technological advance in Wii hacks has come from the people who develop piracy tools. Not one. Every single one of those tools is a rehashing of existing techniques used for other purposes.
What they do is impressive on a superficial level - for people who just want to pirate games.
The dumper used to pirate WiiWare and VC games was based on a technique used for Wii filesystem analysis during the early days (and the person responsible for the warez dumper was asked not to do that by the people who discovered it, which he ignored). I developed the APIs used to install content, for the Homebrew Channel, before they were abused to install pirated WiiWare and VC. The DVD Video mode trick used to read DVD-Rs was developed to play DVDs with mplayer, before being used for piracy. The IOS modification toolset was developed by neimod for homebrew uses, before being abused for piracy. Every single system exploit was discovered and used for homebrew - the softmod people haven't discovered or developed a single entry point into the system. The more difficult and buried IOS patches were developed by bushing as part of PatchMii to enable future IOS experimentation, before being stolen to become part of piracy cIOS mods (although the authors deny this, the identical patches speak for themselves). 99% of the work on softmods can be done by any code monkey. Just because you're coding for a closed platform doesn't mean you're hacking it if you're just using the hacks that someone else developed. Just because you can accomplish something new doesn't mean you developed the foundation for it.
To say that the soft-mod pirate developers are not good hackers is just complete and utter garbage.
Have you seen their code? I have. It's complete and utter garbage (most of the time). I've also seen the lack of safety and the complete ignorance of how the system actually works. I've also seen over one hundred people e-mail me asking for help fixing their Wii after it was bricked by faulty softmod tools (I've yet to see a single person bricked by The Homebrew Channel or BootMii).
Now, this isn't always the case. Some of the pro-piracy hackers doing "back-end" work have done some good work. For example, WiiGator's game loading patch is definitely clever and well-executed, although he doesn't pioneer the underlying techniques. But this is rare; most of the public-facing people in the Wii softmod world don't have a clue what they're doing.
Both sides take from the other side - to say it's all one sided is, again, complete garbage.
I repeat: Wii homebrew has gained practically nothing from wii softmod piracy (Wii modchips did play a role very early on, as bushing mentioned in his comment below). In fact, the only thing that vaguely qualifies for such definition is USB 2.0 IOS support, where the guy who developed it attempted to team up with the softmod guys. He regrets this; he did all of the work and the softmod guy took it and slapped his name and sponsor on it.
After the announcement of the USB copied game launcher, I developed a proof-of-concept USB launcher based on publicly available homebrew tools. I succeeded in 6 hours after 200 lines of original code (and posted video proof). None of the tools I used were developed by people involved in softmods - they all had their legitimate homebrew users before being abused for piracy. A few hours later, the real thing was released, which was widely regarded as the most difficult and technologically advanced piracy tool for the Wii. It equates to 6 hours of actual work, plus polish and a GUI.
As I've said, this may be different on other consoles, but on the Wii, the homebrew com
Geohot has a tendency to overstate things to gain an ego boost and media coverage. In the case of the PS3, he is quite the novice. Throughout this whole saga, he's made numerous technical errors that he later had to correct. This is normal; he had no clue how anything on the PS3 worked when he started. Just don't be misled into thinking he knows exactly what he's doing.
He's not an idiot, and he's learning, but I wouldn't go anywhere near any custom firmware that he puts out at this stage. He can't possibly know what he's doing. Not yet.
Quite the contrary, it's not ridiculous, it's true. Sony's good drive security prevented drivechips (which is where the money's at), and Other OS prevented homebrewers from exploiting the system, which inevitably leads to softmod piracy (which is usually developed by people piggybacking on homebrew hackers for all the hard work). Consoles are hacked for homebrew which is then abused for piracy.
I know quite a few console hackers, and until the Slim's release (no Other OS) the interest in breaking out of the Other OS sandbox was near nil.
That's not a solution to this issue (in fact, it's worse than using a proxy to continue logging in with 3.15). This initiates a cat-and-mouse game with Sony, which will end with annoyed and/or banned users. It also voids the warranty on your console.
As a PS3 Linux user, I don't consider this even remotely as good as the old situation. Sure, functionally at this point in time it might be OK, but the whole point of an officially supported homebrew mode is that it's officially supported. Homebrew after Sony's move was bound to happen and I don't doubt that Other OS will come back, but now the PS3 is effectively like the other consoles - yet another closed platform where hackers play a cat-and-mouse game with the vendor.
I still blame both geohot and Sony for this situation. Geohot for releasing a hack with no useful initial value just to up his ego and get some more media coverage (as if he hasn't had enough already) without thinking about the consequences, and Sony for reacting the way they did. When I was working on the Wii, we were very careful about releases, attempted to establish communications with Nintendo (that didn't work out, but we tried), and thought about the consequences before releasing anything, both in terms of vendor reaction and in terms of usefulness vs. danger for users.
Personally, I am looking into possible legal action against Sony (I think they move isn't legal). If that doesn't work out, I'll just stay on 3.15 with a networking hack until that stops working. Even as a console hacker, it'll take more than a clumsy firmware patch to convince me to void the warranty on my expensive console just because Geohot and Sony pissed each other off. Maybe in a year or so, when my warranty is up, or when something useful comes out of this huge mess, whichever comes first.
It certainly takes some ingenuity and luck to come up with, but it's both simple to reproduce and not too hard to develop in the first place. I think the way geohot came up with it in a short time is a testament to its simplicity (geohot isn't stupid, but I wouldn't consider him a stellar hacker either). I think many other well-known console hackers could've pulled this off in a similar timeframe, it's just that they weren't interested in doing so.
Reproduction, in fact, can be accomplished with decades-old logic. You don't even need to be a modchip hacker, anyone with a cursory knowledge in electronics can make a pulse generator. It's a shotgun approach, so it doesn't rely in introducing any specific behavior or disturbing specific behavior. You're basically just injecting a large-scale fault over and over again until you get lucky.
I think you have some valid points; the PS3 is probably less popular in general, and its security architecture has probably been overstated, which would discourage hackers.
My feeling is that the RSX limitation, while certainly an annoyance for Linux users, just isn't enough to motivate most people into actually breaking the system. Even for those that are, it significantly changes the attack front. A console with no "homebrew mode" needs to be attacked by breaking into the game-mode software, which is what the manufacturer wants to avoid. The PS3, on the other hand, can have small holes poked in the hypervisor without compromising GameOS. This already happened once: a bug was found that enabled the use of the RSX in an older firmware by exploiting some bugs in the hypervisor interface (without actually breaking into it). Sony patched it later.
It's worth noting that this RSX limitation is really the only significant hardware limitation for the PS3 in Other OS. Sure, some other peripherals are virtualized, but you don't really lose any functionality from that. You get access to the full system mode of the PowerPC, and you get access to 6 SPEs which is pretty good.
My personal feeling towards the PS3 (pre-Slim), and I suspect that of many other hackers, was "Meh. No RSX, annoying, but we've got Linux which is pretty good. Maybe we can do some neat tricks with the SPEs". Even if the notion of a walled garden goes against the spirit of controlling your own hardware, it's still so much better than the competition (the iPhone's tightly controlled App Store, the 360's tightly controlled XNA stuff, or the total lack of any reasonable indie game option for the Wii) that it means you tend to go for the other targets. The Wii is particularly bad; they won't let you get an SDK license unless you meet ridiculously high standards - WiiWare is really just a small game option for medium to large game studios, not for small indie operations. The bureaucracy is too large.
I wouldn't want to live in a world where we can't control any of our devices, but I think having "walled gardens" on a few (e.g. mainstream game consoles) is tolerable. I understand the manufacturers' point of view, and why they depend on some software security in order to avoid piracy. Sure, I'd prefer totally open systems, but having some officially-supported homebrew infrastructure still beats having nothing by a large margin.
Read my later post in the replies. I'm talking about softmod piracy. Drive hacks are completely different and are popular because manufacturers neglected drive security while strengthening their software security. The PS3 indeed has decent drive security, which is why it's withstood drive hacks. What I'm saying is that the reason it's withstood software-based piracy is because of Other OS.
Softmod piracy on the Wii piggybacked on homebrew. Recently, 360 soft-piracy (incl. downloadable content, etc.) has taken off or so I'm told, also piggybacking on homebrew. PSP piracy relies exclusively on homebrew, because the media is fully custom and the reader is integrated and you can't reasonably replace/emulate it on a portable. My point still stands; pro-softmod-piracy people (i.e. not modchip companies or drive firmware hackers in the case of the 360) are a) rarely good hackers, and b) piggybacking on homebrew.
And even hen the hack seems to be anything but trivial. Lots of hardware modification needed to crack open it's armor.
To you, it may seem complicated. To me, injecting a single glitch pulse into a RAM line such that sometimes you get lucky and corrupt the right write is a shotgun-style trivial hardware glitch attack. Geohot's hack, hardware-wise, is one of the simplest out there.
I can only speak from my experience in Wii hacking, but I can safely say that the dude who "developed" wii softmod piracy on the Wii did so by duct-taping together existing homebrew in a very poor way. He can barely reverse engineer software and he hasn't contributed a single breakthrough to the hacking community - all he does is leech off of homebrew and present his duct-taped solutions and GUIs as breakthroughs. At the same time, he doesn't understand the implications of what he does, nor does he properly comprehend the system architecture, and he also doesn't bother with safety. This conspires to make Wii softmod particularly dangerous to the uninitiated, as you're almost guaranteed to permanently brick your Wii if you blindly do stuff, and still dangerous even for experienced pirates, as some of his tools just flat out randomly brick consoles for no reason at all.
The day he preannounced his USB loader for the Wii (something highly predictable, as someone had recently released high-speed USB drivers for homebrew), I decided to carry out an exercise and see how long it would take me to build the core functionality by doing what he does - duct-tape together existing modules and tools. The answer is that what is widely considered to be his major breakthrough amounts to 6 hours of actual work, plus polish and a bad GUI. I had a video proof-of-concept going before he even had a chance to release his loader.
It might be different on other consoles; that I do not know.
Yes, that part of the table is wrong (IMO it should read 12 months or whatever). However, this warrants some explanation.
Since the advent of drive modifications and consoles with signed executables, piracy has split into two camps: drive modification, and software modification. The latter implies homebrew and always piggybacks on homebrew, and is mostly what I refer to in my GP post. However, drive modifications are a different story. They mostly appeared when drive firmware patches delivered via homebrew on the GameCube were ported by modchip manufacturers to be delivered via an alternate serial port on the drive. The GC/Wii's drives are outsourced to Matshita, and they didn't bother to fix the hole in the GameCube. Paraphrasing tmbinc, "The GameCube had a connector on the drive board that might as well have been labeled 'insert modchip here'. With the Wii, they fixed this problem by removing the old connector... and replacing it with a new one".
Therefore, it is safe to say that DVD (drive) piracy on the Wii was there from the very beginning - not because the modchip makers are good, but because modchips were trivially ported over from the GameCube. On the other hand, softmod piracy on the Wii started, as usual, by piggybacking on homebrew.
The reason that drive mods are popular is because manufacturers have neglected that part of console security - they made their software secure, but didn't properly secure the drive. If you can convince a drive that a burned game is legit, then there's nothing that the console software can do about it. In order to fix this, you need to improve drive security and couple it to system security.
The Wii is the worst example - the drive bus is in plaintext and unauthenticated. This is why HDD-to-drive physical adapters are coming out from modchip makers.
The 360 is better, but the drives are essentially off-the-shelf PC drives. Although they're trying hard to detect and ban mods, and there's some crypto going on, the drives are still pretty insecure.
The PS3 is different; as far as I know, the BD drive is custom, secure, and much better coupled to the system.
So, to conclude and better explain things: the PS3 avoided commercial drivechips by having good drive security (something sorely lacking on other consoles), and avoided noncommercial software piracy by removing the incentive for homebrewers to hack the system (which will inevitably happen otherwise, as has been proven time and time again).
And yet the PS3 isn't tougher to hack in the way geohot has (certainly not given Other OS). Look at geohot's hack: it's a simple RAM glitch, much like the one tmbinc pioneered over 2 years ago on the Wii ("twiizer attack"). Now that hacks are out for all consoles, we can compare the relative difficulty. Compare the PS3 (plaintext hypervisor in RAM, no hashing) to the Xbox 360 (encrypted hypervisor in RAM, hashing, encrypted executables). Both consoles have good security, but the PS3 hack is significantly simpler than 360 hacks from a technical perspective (drive hacks notwithstanding - that's a whole different ballgame). That's also confirmed given how little time it took geohot to get it to work, even though he was completely unfamiliar with the PS3 when he started a few months earlier. Even the Xbox1 LDT bus tap by Andrew "bunnie" Huang was orders of magnitude more complicated, and yet he pulled it off in 2001.
As a console hacker myself, I know quite a few others, and I can definitely say that interest in hacking the PS3 was near nonexistent before the Slim came out (sans Other OS), except for a couple Linux folks trying to poke holes in the hypercall interface to get access to the GPU.
The clock problem didn't affect all fat PS3s. I have a later model (a year or so old) and it worked fine on March 1st. I made a point to try to connect to PSN to see whether the bug would be triggered or not.
No, there are two words to explain that: Other OS. Check out this table (slightly outdated, it's a year old or so) by console hacker Michael Steil (or watch him talk about it on any of his talks). Every console post-PS2 was hacked for homebrew, and then those hacks were abused for piracy. The PS3 comes with homebrew, therefore there is little motivation to crack the native system. Pro-piracy people are rarely good hackers, and need homebrew to piggyback on. In fact, the reason the PS3 was recently attacked was neither homebrew nor piracy; instead, geohot attacked it solely as an ego boost and to get media coverage (note how he hasn't even tried to develop a useful application for his exploit, such as GPU access under Linux).
Blu-ray is a minor inconvenience. There are a myriad potential ways of copying PS3 games that don't involve blu-ray discs.
Sony are shooting themselves in the foot by removing Other OS, and pissing off legitimate customers on top of it.
Slashdot Mirror
Xraying the chip won't tell you what it is. Decapping it and observing it under a microscope will. Chipworks did both.
The guy who wrote the article is clueless.
These ridiculous claims remind me of that "tapionvslink" guy who swears that the Wii has a GPGPU with programmable shaders and twice the RAM and all sorts of things that the homebrew community knows are bullshit, just because he did some broken math on die sizes. He still maintains that we're all ignorant and just haven't figured out what real Wii games are doing with the GPU. Riiight.
Seriously, if the iPad were PowerPC, don't you think we'd know by now, considering it's been jailbroken? Chipworks also tore down the chip and found nothing unusual; it's just another mobile ARM. Also, no one in their right mind would ever use a CPU emulator on a mobile platform OS. It's one of the best ways to completely nuke your battery life, not to mention performance. It's a cute theory, but it's so thoroughly impossible it's not even funny.
One of the many exploits that we've used to own the Wii (in fact, the very first runtime IOS exploit that we used, which I found and implemented) was a NULL pointer dereference bug, and it wasn't even a function pointer.
I wrote a detailed blog post about it recently. The short version is that they doubly dereference a near-NULL address and write to it, and NULL happens to be real physical memory that we control (call it 'insecure', if you wil). The double dereference lets us direct the write anywhere, including the stack, and it's game over. That's the "usermode" exploit. Privilege escalation into the kernel is trivial because they have some huge kernel holes. The fact that they map the 'insecure' memory as executable (!) in every application makes it even easier.
I'm tired of people shoehorning the power-hungry x86 architecture into small devices. If there's one thing that Apple did right it's not using the Atom. The WePad runs Linux: there's no reason to stick with the legacy x86 architecture. Even Adobe Flash works on ARM (just not Flash 10 yet).
If the WePad used an ARM chip, it could probably retain its feature set and bump up the battery duration to the iPad level, which seems to be the only feature where it loses to it.
Just do what I do. I use relatively strong passwords. On places which require password replacement, I just append an ever-incrementing number, while still keeping the strong password part. This effectively bypasses the aging and lets you keep using the same password (a single incrementing number should be easy to remember, and you can always try a few times).
I've never been able to play fullscreen SD content, much less HD content, with Flash under Linux. x86_64, latest adobe labs 64bit player. At least not without the video skipping two out of three frames and generally bogging down the entire windowing system. And don't even think about using apps that perform any processing on the video (YouTube 3D? Hope you like your 4fps windowed, 2fps fullscreen).
I'm still waiting for the magical how-to-make-Flash-not-suck guide from the people who claim that Flash does indeed work OK. Until then, I'm sticking to mplayer -fs /tmp/Flash* to play fullscreen YouTube videos.
By that token, if homebrew hackers and piracy hackers were about on the same level, we should see about half of all consoles get hacked for piracy and then homebrew, and half get hacked for homebrew and then piracy. In fact, what we have seen is the latter in every case since the PS2, except for the only console where homebrew already existed in some officially supported form.
There's a distinction between the people providing the hacks (code execution entry points for homebrew, game loading patches / modules for piracy, as well as the low-level hardware reverse engineering and frameworks) and the people using them (people who write homebrew apps, or people who write / modify game loaders that rely on those patches). Arguably the former need to be more skilled hackers than the latter, as you need knowledge of the system architecture, not just knowledge of an API and generic programming. Of course there's a lot of crap built on top of homebrew libs and piracy tools alike. What I'm saying is that the people responsible for homebrew, in my experience with the Wii, write much better code than the people responsible for piracy. In fact, I'm willing to say that the "core" people responsible for piracy are worse coders than many homebrew application coders. For example, there are some homebrew tools that perform some benign system modifications, and these have (some) proper safety checks, while the tools written by the piracy guys don't.
This reminds me of another benchmark: the contribution to homebrew libs (used for regular homebrew and piracy tools alike) by the guy responsible for most of the piracy tools amounts to precisely one trivial patch which added support for reading a few extra system settings (that I hadn't bothered to implement back when I wrote the original system setting code). Take that however you want, I'm just putting it out as an example of just how insignificantly little piracy has contributed to homebrew.
I never said that all pro-piracy console hackers are idiots. I'm saying that the vast majority of pro-piracy Wii hackers are idiots (which I know because I spent two years working with the Wii), and that is is my impression that, in general, pro-piracy hackers tend not to be as good as pro-homebrew hackers and, therefore, tend to rely and depend upon the latter to kickstart piracy on a console. This is a conclusion that I draw from the available data (Wii plus the general statistic as seen in the table above), as well as comments by other console hackers. I only make a strong statement that Wii piracy hackers suck, not that all piracy console hackers suck.
That's one way to see it. The way I see it is that piracy isn't inherently dangerous, or at least not any more so than homebrew. Instead, the danger is caused by the generally low quality of piracy tools, as a consequence of the lesser skill of the people producing them. Homebrew entry points and exploits aren't exactly the cleanest code ever, bu
WTF, is slashdot posting my comments as AC for some reason? It happened earlier too :/
Why on earth did I post this AC? The mind boggles.
Chances are the OS is going to be exactly the same, and you can tweak a plist file on a jailbroken phone to enable multitasking on older devices. You can easily make a 3G think it's a 3GS. The feature will be there, just disabled.
No it doesn't, unless the apps are crap. The real problem is RAM, not CPU. On a 3G, you can run 5-7 lightweight apps with ease, but you can barely run 2 heavyweight apps at once. The symptom is that it runs out of RAM, freezes for a short while, then kills one of the apps.
For example, right now, I just backgrounded Messages, Photos, Notes, Weather, Clock, Calculator, and Voice Memos. That worked fine; those are very lightweight. Then I opened Twitterific, which is starting to push things. Nothing got killed yet though. Then I opened Maps, and that pushed it over the edge; Clock and Notes got killed. Then I opened YouTube and hit a video, and that nuked Calculator and Voice Memos, plus YouTube itself refused to background and got killed as I hit home. Then I opened iPod to listen to some music, which worked fine thanks to the defunct YouTube. But once you open Cydia, abandon all hope; everything but iPod gets killed.
I get 56fps with Firefox 3.5.8 under Linux and 64 images. Even 30fps with 256 images. Something isn't right about this benchmark.
Those things were developed for homebrew and legitimate modding, then duct-taped together to enable piracy.
Not a single technological advance in Wii hacks has come from the people who develop piracy tools. Not one. Every single one of those tools is a rehashing of existing techniques used for other purposes.
What they do is impressive on a superficial level - for people who just want to pirate games.
The dumper used to pirate WiiWare and VC games was based on a technique used for Wii filesystem analysis during the early days (and the person responsible for the warez dumper was asked not to do that by the people who discovered it, which he ignored). I developed the APIs used to install content, for the Homebrew Channel, before they were abused to install pirated WiiWare and VC. The DVD Video mode trick used to read DVD-Rs was developed to play DVDs with mplayer, before being used for piracy. The IOS modification toolset was developed by neimod for homebrew uses, before being abused for piracy. Every single system exploit was discovered and used for homebrew - the softmod people haven't discovered or developed a single entry point into the system. The more difficult and buried IOS patches were developed by bushing as part of PatchMii to enable future IOS experimentation, before being stolen to become part of piracy cIOS mods (although the authors deny this, the identical patches speak for themselves). 99% of the work on softmods can be done by any code monkey. Just because you're coding for a closed platform doesn't mean you're hacking it if you're just using the hacks that someone else developed. Just because you can accomplish something new doesn't mean you developed the foundation for it.
Have you seen their code? I have. It's complete and utter garbage (most of the time). I've also seen the lack of safety and the complete ignorance of how the system actually works. I've also seen over one hundred people e-mail me asking for help fixing their Wii after it was bricked by faulty softmod tools (I've yet to see a single person bricked by The Homebrew Channel or BootMii).
Now, this isn't always the case. Some of the pro-piracy hackers doing "back-end" work have done some good work. For example, WiiGator's game loading patch is definitely clever and well-executed, although he doesn't pioneer the underlying techniques. But this is rare; most of the public-facing people in the Wii softmod world don't have a clue what they're doing.
I repeat: Wii homebrew has gained practically nothing from wii softmod piracy (Wii modchips did play a role very early on, as bushing mentioned in his comment below). In fact, the only thing that vaguely qualifies for such definition is USB 2.0 IOS support, where the guy who developed it attempted to team up with the softmod guys. He regrets this; he did all of the work and the softmod guy took it and slapped his name and sponsor on it.
After the announcement of the USB copied game launcher, I developed a proof-of-concept USB launcher based on publicly available homebrew tools. I succeeded in 6 hours after 200 lines of original code (and posted video proof). None of the tools I used were developed by people involved in softmods - they all had their legitimate homebrew users before being abused for piracy. A few hours later, the real thing was released, which was widely regarded as the most difficult and technologically advanced piracy tool for the Wii. It equates to 6 hours of actual work, plus polish and a GUI.
As I've said, this may be different on other consoles, but on the Wii, the homebrew com
Geohot has a tendency to overstate things to gain an ego boost and media coverage. In the case of the PS3, he is quite the novice. Throughout this whole saga, he's made numerous technical errors that he later had to correct. This is normal; he had no clue how anything on the PS3 worked when he started. Just don't be misled into thinking he knows exactly what he's doing.
He's not an idiot, and he's learning, but I wouldn't go anywhere near any custom firmware that he puts out at this stage. He can't possibly know what he's doing. Not yet.
Quite the contrary, it's not ridiculous, it's true. Sony's good drive security prevented drivechips (which is where the money's at), and Other OS prevented homebrewers from exploiting the system, which inevitably leads to softmod piracy (which is usually developed by people piggybacking on homebrew hackers for all the hard work). Consoles are hacked for homebrew which is then abused for piracy.
I know quite a few console hackers, and until the Slim's release (no Other OS) the interest in breaking out of the Other OS sandbox was near nil.
That's not a solution to this issue (in fact, it's worse than using a proxy to continue logging in with 3.15). This initiates a cat-and-mouse game with Sony, which will end with annoyed and/or banned users. It also voids the warranty on your console.
As a PS3 Linux user, I don't consider this even remotely as good as the old situation. Sure, functionally at this point in time it might be OK, but the whole point of an officially supported homebrew mode is that it's officially supported. Homebrew after Sony's move was bound to happen and I don't doubt that Other OS will come back, but now the PS3 is effectively like the other consoles - yet another closed platform where hackers play a cat-and-mouse game with the vendor.
I still blame both geohot and Sony for this situation. Geohot for releasing a hack with no useful initial value just to up his ego and get some more media coverage (as if he hasn't had enough already) without thinking about the consequences, and Sony for reacting the way they did. When I was working on the Wii, we were very careful about releases, attempted to establish communications with Nintendo (that didn't work out, but we tried), and thought about the consequences before releasing anything, both in terms of vendor reaction and in terms of usefulness vs. danger for users.
Personally, I am looking into possible legal action against Sony (I think they move isn't legal). If that doesn't work out, I'll just stay on 3.15 with a networking hack until that stops working. Even as a console hacker, it'll take more than a clumsy firmware patch to convince me to void the warranty on my expensive console just because Geohot and Sony pissed each other off. Maybe in a year or so, when my warranty is up, or when something useful comes out of this huge mess, whichever comes first.
It certainly takes some ingenuity and luck to come up with, but it's both simple to reproduce and not too hard to develop in the first place. I think the way geohot came up with it in a short time is a testament to its simplicity (geohot isn't stupid, but I wouldn't consider him a stellar hacker either). I think many other well-known console hackers could've pulled this off in a similar timeframe, it's just that they weren't interested in doing so.
Reproduction, in fact, can be accomplished with decades-old logic. You don't even need to be a modchip hacker, anyone with a cursory knowledge in electronics can make a pulse generator. It's a shotgun approach, so it doesn't rely in introducing any specific behavior or disturbing specific behavior. You're basically just injecting a large-scale fault over and over again until you get lucky.
I think you have some valid points; the PS3 is probably less popular in general, and its security architecture has probably been overstated, which would discourage hackers.
My feeling is that the RSX limitation, while certainly an annoyance for Linux users, just isn't enough to motivate most people into actually breaking the system. Even for those that are, it significantly changes the attack front. A console with no "homebrew mode" needs to be attacked by breaking into the game-mode software, which is what the manufacturer wants to avoid. The PS3, on the other hand, can have small holes poked in the hypervisor without compromising GameOS. This already happened once: a bug was found that enabled the use of the RSX in an older firmware by exploiting some bugs in the hypervisor interface (without actually breaking into it). Sony patched it later.
It's worth noting that this RSX limitation is really the only significant hardware limitation for the PS3 in Other OS. Sure, some other peripherals are virtualized, but you don't really lose any functionality from that. You get access to the full system mode of the PowerPC, and you get access to 6 SPEs which is pretty good.
My personal feeling towards the PS3 (pre-Slim), and I suspect that of many other hackers, was "Meh. No RSX, annoying, but we've got Linux which is pretty good. Maybe we can do some neat tricks with the SPEs". Even if the notion of a walled garden goes against the spirit of controlling your own hardware, it's still so much better than the competition (the iPhone's tightly controlled App Store, the 360's tightly controlled XNA stuff, or the total lack of any reasonable indie game option for the Wii) that it means you tend to go for the other targets. The Wii is particularly bad; they won't let you get an SDK license unless you meet ridiculously high standards - WiiWare is really just a small game option for medium to large game studios, not for small indie operations. The bureaucracy is too large.
I wouldn't want to live in a world where we can't control any of our devices, but I think having "walled gardens" on a few (e.g. mainstream game consoles) is tolerable. I understand the manufacturers' point of view, and why they depend on some software security in order to avoid piracy. Sure, I'd prefer totally open systems, but having some officially-supported homebrew infrastructure still beats having nothing by a large margin.
Read my later post in the replies. I'm talking about softmod piracy. Drive hacks are completely different and are popular because manufacturers neglected drive security while strengthening their software security. The PS3 indeed has decent drive security, which is why it's withstood drive hacks. What I'm saying is that the reason it's withstood software-based piracy is because of Other OS.
Softmod piracy on the Wii piggybacked on homebrew. Recently, 360 soft-piracy (incl. downloadable content, etc.) has taken off or so I'm told, also piggybacking on homebrew. PSP piracy relies exclusively on homebrew, because the media is fully custom and the reader is integrated and you can't reasonably replace/emulate it on a portable. My point still stands; pro-softmod-piracy people (i.e. not modchip companies or drive firmware hackers in the case of the 360) are a) rarely good hackers, and b) piggybacking on homebrew.
To you, it may seem complicated. To me, injecting a single glitch pulse into a RAM line such that sometimes you get lucky and corrupt the right write is a shotgun-style trivial hardware glitch attack. Geohot's hack, hardware-wise, is one of the simplest out there.
I can only speak from my experience in Wii hacking, but I can safely say that the dude who "developed" wii softmod piracy on the Wii did so by duct-taping together existing homebrew in a very poor way. He can barely reverse engineer software and he hasn't contributed a single breakthrough to the hacking community - all he does is leech off of homebrew and present his duct-taped solutions and GUIs as breakthroughs. At the same time, he doesn't understand the implications of what he does, nor does he properly comprehend the system architecture, and he also doesn't bother with safety. This conspires to make Wii softmod particularly dangerous to the uninitiated, as you're almost guaranteed to permanently brick your Wii if you blindly do stuff, and still dangerous even for experienced pirates, as some of his tools just flat out randomly brick consoles for no reason at all.
The day he preannounced his USB loader for the Wii (something highly predictable, as someone had recently released high-speed USB drivers for homebrew), I decided to carry out an exercise and see how long it would take me to build the core functionality by doing what he does - duct-tape together existing modules and tools. The answer is that what is widely considered to be his major breakthrough amounts to 6 hours of actual work, plus polish and a bad GUI. I had a video proof-of-concept going before he even had a chance to release his loader.
It might be different on other consoles; that I do not know.
Yes, that part of the table is wrong (IMO it should read 12 months or whatever). However, this warrants some explanation.
Since the advent of drive modifications and consoles with signed executables, piracy has split into two camps: drive modification, and software modification. The latter implies homebrew and always piggybacks on homebrew, and is mostly what I refer to in my GP post. However, drive modifications are a different story. They mostly appeared when drive firmware patches delivered via homebrew on the GameCube were ported by modchip manufacturers to be delivered via an alternate serial port on the drive. The GC/Wii's drives are outsourced to Matshita, and they didn't bother to fix the hole in the GameCube. Paraphrasing tmbinc, "The GameCube had a connector on the drive board that might as well have been labeled 'insert modchip here'. With the Wii, they fixed this problem by removing the old connector... and replacing it with a new one".
Therefore, it is safe to say that DVD (drive) piracy on the Wii was there from the very beginning - not because the modchip makers are good, but because modchips were trivially ported over from the GameCube. On the other hand, softmod piracy on the Wii started, as usual, by piggybacking on homebrew.
The reason that drive mods are popular is because manufacturers have neglected that part of console security - they made their software secure, but didn't properly secure the drive. If you can convince a drive that a burned game is legit, then there's nothing that the console software can do about it. In order to fix this, you need to improve drive security and couple it to system security.
The Wii is the worst example - the drive bus is in plaintext and unauthenticated. This is why HDD-to-drive physical adapters are coming out from modchip makers.
The 360 is better, but the drives are essentially off-the-shelf PC drives. Although they're trying hard to detect and ban mods, and there's some crypto going on, the drives are still pretty insecure.
The PS3 is different; as far as I know, the BD drive is custom, secure, and much better coupled to the system.
So, to conclude and better explain things: the PS3 avoided commercial drivechips by having good drive security (something sorely lacking on other consoles), and avoided noncommercial software piracy by removing the incentive for homebrewers to hack the system (which will inevitably happen otherwise, as has been proven time and time again).
And yet the PS3 isn't tougher to hack in the way geohot has (certainly not given Other OS). Look at geohot's hack: it's a simple RAM glitch, much like the one tmbinc pioneered over 2 years ago on the Wii ("twiizer attack"). Now that hacks are out for all consoles, we can compare the relative difficulty. Compare the PS3 (plaintext hypervisor in RAM, no hashing) to the Xbox 360 (encrypted hypervisor in RAM, hashing, encrypted executables). Both consoles have good security, but the PS3 hack is significantly simpler than 360 hacks from a technical perspective (drive hacks notwithstanding - that's a whole different ballgame). That's also confirmed given how little time it took geohot to get it to work, even though he was completely unfamiliar with the PS3 when he started a few months earlier. Even the Xbox1 LDT bus tap by Andrew "bunnie" Huang was orders of magnitude more complicated, and yet he pulled it off in 2001.
As a console hacker myself, I know quite a few others, and I can definitely say that interest in hacking the PS3 was near nonexistent before the Slim came out (sans Other OS), except for a couple Linux folks trying to poke holes in the hypercall interface to get access to the GPU.
The clock problem didn't affect all fat PS3s. I have a later model (a year or so old) and it worked fine on March 1st. I made a point to try to connect to PSN to see whether the bug would be triggered or not.
No, there are two words to explain that: Other OS. Check out this table (slightly outdated, it's a year old or so) by console hacker Michael Steil (or watch him talk about it on any of his talks). Every console post-PS2 was hacked for homebrew, and then those hacks were abused for piracy. The PS3 comes with homebrew, therefore there is little motivation to crack the native system. Pro-piracy people are rarely good hackers, and need homebrew to piggyback on. In fact, the reason the PS3 was recently attacked was neither homebrew nor piracy; instead, geohot attacked it solely as an ego boost and to get media coverage (note how he hasn't even tried to develop a useful application for his exploit, such as GPU access under Linux).
Blu-ray is a minor inconvenience. There are a myriad potential ways of copying PS3 games that don't involve blu-ray discs.
Sony are shooting themselves in the foot by removing Other OS, and pissing off legitimate customers on top of it.