the PS3 stack smash. (Seriously, who thinks of that attack vector)
Stack smashes are easy. The PS3 exploit is a complex interaction with multiple noncompliant USB devices and is still not fully understood. All we know is a pointer to a function pointer gets overwritten with attacker-controlled data (the end of a USB descriptor) and the rest is history, but the circumstances leading to that overwrite are much more complicated than your average exploit. And none of it has anything to do with the stack (as far as we know anyway!). Phiren claims it's a heap overflow overwriting a malloc boundary tag, but I'm not convinced.
I did mention that (some of) the headers contain code, especially graphics-related ones that include static inline functions or #define macros for speed.
And even then, just merely using a library's headers and dynamically linking to it is definitely not as clear cut as you make it sound. Just ask the FSF; at least they swear and maintain that (dynamically or statically) linking against GPLed code means you are bound by the terms of the GPL. At some point, a library interface ceases to be a "database of facts". Consider a complex library that defines a multitude of interfaces including data structures. Just because there is no executable code doesn't mean the interface and its structures and their definitions cannot be considered a creative work.
This is a moot point, though, because code compiled with the Sony SDK statically links in their libraries.
Remember: a copyrighted work must have some creative input. It is not the binary components of the SDK that Sony claim copyright on, rather it is the source-code behind them which was created by a human.
The copyrightable material is created in the form of source code, but that copyright status is maintained through any transformations, manual or automated. Binary code has as much creative input as the source code it is produced from.
I haven't checked the details, but I'm willing to bet that the physical differential signaling levels used for PCIe (LVDS) and SAS/SATA are pretty similar. As long as they at least kept the transmit/receive pairs in the same place, I bet that plugging in the wrong type of device will probably just cause error reports from the controller or at worst severely confuse the device and/or controller, but won't cause any permanent damage.
Your game is not functional as an SDK in itself, so it is not derivative.
That's not how copyright works. Derivative works don't have to be in the same class or perform the same function as the original, they just have to be derivative.
the call to a certain function presumably always lies at the same address in flash / memory
Static linking doesn't work like that. Your final binary includes large chunks of the SDK inside it (for typical homebrew, the SDK portions are larger than the homebrew itself). And the addresses of those chunks of code change depending on how things get linked. It's the same output that you would get if you had the full source code of the SDK libraries and used it as part of your app, except you don't get to see or change that code. The end result, nonetheless, includes a fully relocated and linked version of it.
Their terms are wrong, and I'm surprised they are legally enforceable. Well no, I'm not surprised because judges don't need to be knowledgeable in the cases they try, and this is the US we are talking about, where the legal system is fucked up anyway.
I don't see why there would be an issue enforcing a license which is clearly being violated if you're not an authorized developer. Doing what you want with your own hardware is/should be a right, but you don't have the right to getting a convenient SDK for it.
Sony are simply trying to equate using something as making a derivative copy of something, which is absolute nonsense.
They are, in fact, equivalent, in this case, as I've explained. This is how embedded SDKs work. This isn't new and applies to every console SDK and also pretty much every embedded SDK. It even applies to PC applications, just to a lesser extent: library code is usually dynamically linked, but header files are statically included, your program includes the compiler's support functions (e.g. floating point emulation where necessary, and general support routines such as function prologue and exception handling helpers). You also use the library's crt0 startup code. Again, these things come with licensing exceptions (e.g. libgcc comes with a linking exception) that we take for granted, but those licensing exceptions are still required.
Compiling code with a development system isn't like producing a data file with an application (e.g. making a document in a word processor). Software compilation always involves copying (sometimes large) parts of code from the SDK into your app.
Now s/piano/SDK and s/music/game... see what I mean ?
Using prototype.js or jQuery on your Web application means you COPY them into your website and include them via script tags.
Now s/jQuery/SDK/ and s/Web application/game/ and s/script tags/static linking/. See what I mean?
(ignore the fact that you can include them from external URLs; this isn't an option on consoles. You have to pretend that instead of <script src=...> you actually copy and paste the entire thing into an inline <script> block)
by that I mean you have to alter the source and recompile to enable it
There is no source, as the payload is a hacked (hex edited) version of the original PSJailbreak payload. All they did was change the string/dev_bdvd to something else, to break the functionality. All you need to do is get a hex editor and change those four characters back to bdvd.
is it as simple as you claim, is the code that allows blu-ray redirection completely unused by the rest of the payload
Pretty much, yes. It's a special call that invokes special code to trigger the redirection. You can get rid of all of that and still keep the debug package patches and the unsigned code patch.
Not exactly; if compiling "with" it means including some part of it for distribution then it is clearly a violation. But normally compiling with an SDK means compiling against it: distributing code that calls it, but not the SDK code itself. This is not a violation of copyright.
Compiling code against the SDK implies including SDK headers (which are considered copyrightable, especially for nontrivial ones; for example, lots of GPU code is inlined in headers for speed) and statically linking SDK libraries (this isn't a PC where most things are dynamically linked). Both of these clearly produce a derivative work.
Normally, PC SDKs and similar have redistribution licenses that cover the redistributable parts of the SDK. These licenses are often taken for granted, but they need to be there. Console SDKs have different licenses that only apply if you're an authorized developer with a license to use the SDK and who is publishing through the console manufacturer.
Of course, you can use Sony's SDK's compiler (which is a GCC fork) to build some app that doesn't use any of their libraries (careful though, you'll have to use -ffreestanding and -nostartfiles and -nostdlibs, otherwise you link in their crt0.o and libc!), and distributing that app would be legal, but this is a totally pointless exercise because you can trivially build a PowerPC GCC that does the same. The useful parts of the SDK are the headers and statically linked libraries.
They aren't distributing the SDK itself, so no copyright has been infringed.
Yes they are. Once you include SDK headers or link your application with the SDK libraries, it becomes a derivative work and for our intents and purposes equivalent to distributing portions of the SDK.
Most SDKs have special license provisions that allow this, which is common sense (otherwise the SDK would be useless). Those license provisions aren't as broad for console SDKs, nor do they apply if you aren't a legal user of the SDK to begin with. If you aren't an authorized Sony developer publishing your game through Sony, you aren't licensed to use or link with or distribute code built with the Sony PS3 SDK, as doing so means redistributing portions of said SDK, which is copyright infringement without a license.
Since I am interested in homebrew, not backups, I simply do not endorse or associate myself with tools that enable copies (legitimate or not).
There is no practical way to allow fair use backups while not allowing piracy. Therefore, as a homebrew developer, it's a hell of a lot easier to just stay away from the entire business of copying games. Would it be nice to be able to back up games? Absolutely. But I don't consider it essential, and involving yourself with it inevitable means associating yourself with piracy, which is something I think homebrew developers would do best to avoid.
Besides, it's not like backing up your games is an inherent expectation when buying a console. Everyone knows full well that the DRM restricts their rights. It's not our job to fully and completely crack every aspect of the DRM for every purpose; if you really dislike some aspect of the DRM, then you probably should've voted with your wallet and not have bought the system in the first place.
Well, no. That has to be/proven/, not suspected or rounded off with loose terms like "probably"
The proof is simply the device's marketing, which centers around running "backups", which even a stupid judge can understand is an euphemism for "pirate copies" most of the time. Even if you drink the "backups" kool-aid, it's still letting you bypass the technical protection measures (whether for legitimate use or not) and, therefore, it's a circumvention device.
Again, that's not enough to logically negate the validity of legal use.
The issue is that courts aren't going to care that legal uses exist if those legal uses are used by a tiny minority of people. Every circumvention device, by definition, has legal uses (since customers are being denied their rights by the DRM), but circumvention devices are still mostly illegal. If your legal uses are broad enough to have significant weight (see e.g. iPhone jailbreaks), then you might get an exemption or similar. Another option is to remove the functionality that enables the actual copying to attempt to get the "circumvention device" label slapped on whatever is developed to piggyback on your hack and ultimately play copied games. This is what I'm advocating.
It shouldn't, but it is. Personally, I think it'd be great if the whole "circumvention device" nonsense went away and instead companies focused on cracking down on actual copiers. However, the current US law is what it is, and it isn't going to magically change now. Devices to "jailbreak" (horrible term, blatantly ripped from the iPhone scene, does not really apply here) your PS3 with the ability to play copied games are not currently legal in the US, whether you plan to exercise that ability to pirate games or not.
Whether the software explicitly enables or partially enables copying games (i.e. includes functionality specifically for this purpose) instead of merely doing so as a side effect of a general security bypass hack (e.g. simply enabling copied PSN games by merely allowing unsigned code) can be legally significant.
iPhone jailbreaks are in little legal trouble lately, among other reasons, because none of them have any functinoality related to pirating App Store apps. Those apps can be ripped, decrypted, and installed as any unofficial app, but the jailbreak itself includes no functionality to aid in this process; it is a mere consequence of the ability to install unsigned apps. Contrast this with including code that is specifically and exclusively designed to play copied Blu-Ray games.
Nope, I just have a lot of practical experience with the group of people who collectively insist that they're "backing up their games", and how the vast majority are obviously pirates. Most are either outwardly pirating (and they just substitute the term 'backup' because it's cool, but otherwise outwardly acknowledge illegally downloading and copying games), or don't try very hard to hide it.
It's also common sense. Do you honestly believe that there's even a tiny chance that most people hacking their consoles aren't doing it for piracy? Especially with the PS3, where there has been an explosion of people who are out to buy or make a PSJailbreak clone, even though there's just about no useful homebrew for it yet.
The problem is that all of the code is still there and working, they just changed a single string to subtly break it. Right, this "does the job", but it makes it so ridiculously easy to reenable that it could be considered similar to, say, openly selling a game console cheat device that just happens to enable loading copies if you hit the right button combination, load the right hacked configuration file, or enter the right magic cheat code. It's still dodgy.
And heck, I know full well that the people responsible for these open clones (at least the original PSGroove and PSFreedom authors) are perfectly capable of rewriting the code to yank out the piracy parts (and save a lot of space; for technical reasons, the payload is pretty constrained), especially seeing as it's been analyzed pretty thoroughly by now. This is why I'm advocating at least taking the (not much) time to make an independently compilable reimplementation that entirely does away with all of the redirect code, instead of just trivially disabling it.
I would normally prefer the term "the copied-game-loading code", which is more correctly neutral, but sometimes I get so irritated by all the lying smartasses who use the term "backup" as a thin veil (and thus discredit the minority of people actually legitimately backing up their own games) that I feel like using a term that is biased the other way just to make it blatantly obvious what most people end up using the code for.
Specifically, I'm talking about the Blu-Ray redirection patches which are still present in the PSGroove code (which is just a version of the PSJailbreak code hex-edited to trivially break, but not remove, this functionality). In other words, the PSGroove is technically a pirated PSJailbreak (not that I care about commercial game copying products getting copied, but there are legal implications to basing your stuff too much on a piracy device). It's a lot cleaner if you just take the required core concept of the exploit and develop an open product around it that shares nothing more than what is strictly necessary with the original.
Wow - using an SDK is piracy?
Torrenting it and then distributing code compiled with it both are, which is what everyone who is using the Sony SDK did. Copyright infringement is copyright infringement. If Sony didn't grant you a license to use the PS3 SDK, then you aren't allowed to legally use it.
The DMCA exceptions are revised every 3 years and the recent phone jailbreaking exception singles out phones and does not apply to consoles. The primary purpose of the device (the PSJailbreak) that started this is piracy, and this is what the vast majority of people using the device and its clones are doing. Even though the homebrew clones are trying to move away from it, currently, they still share quite a bit of the piracy code. Worse, currently, all installable PS3 homebrew is developed with the leaked Sony SDK, which, in and of itself, is also piracy.
I'm not saying Sony's case is a good idea, but they have a much better case than Apple would right now.
Personally, I'm working on using the PSJailbreak exploit (not any of its code, payload, patches, or functionality) to run a fully original payload that will eventually boot Linux as GameOS (with access to the 3D hardware, but otherwise similar to OtherOS). In order to avoid legal trouble, I would recommend that open source PS3 hack authors do something along similar lines and distance themselves from the original game-loading payload and the Sony SDK (and even GameOS). If you do that, then you seriously cut down on the number of things that Sony's lawyers can grab on to for a case.
Or you could say that by removing that functionality they made the hacking take longer to finish making working backups than if they had ignored the whole issue.
That makes no sense. After Sony pulled OtherOS, anyone who cared to continue hacking just didn't update and continued hacking on the older versions.
it was only when we tried to make easy PS3 game backups that they bothered
The OtherOS RAM glitching attack was impractical and had nothing to do with piracy, and yet Sony were stupid enough to not only care, but direct attention towards GameOS which is precisely the target that would be ripe for piracy exploits.
It may lead to a more open PS3, but will result in the PS4 being considerably less open as an attempt to counter the hacking.
Sony already blew it by pulling OtherOS. If the PS4 is less open, then, as usual, chances are it will be attacked earlier and by more dedicated homebrew hackers, and it will lead to piracy earlier. The PS3 was the most open system this generation, and also the one that lasted the longest without piracy. This isn't a coincidence. Sony can either learn the lesson and open up the PS4, or not do so and end up like all the others (somewhat outdated table).
The USB exploit was discovered and used by a piracy company/manufacturer, but it is practically guaranteed that they built off of the then-early homebrew hacks for its development (the geohot glitching exploit and xorloser's xorhack toolkit, to name a couple), even though the final product was condensed down to a piracy device. These early homebrew hacks started off as a response to Sony pulling OtherOS from the Slim and ballooned after Sony illegitimately pulled OtherOS from all existing consoles.
The PS3 has doubtlessly been under attack from would-be piracy companies since its release. Given the timing involved, I think we can safely say that the PSJailbreak piracy device wouldn't have happened had Sony not pulled OtherOS and prompted homebrew hackers to start breaking into the system, paving the way for thorough analysis. Though admittedly in this case the PSJailbreak developers did more of the work than you'd normally expect (usually, homebrew is well on its way before piracy companies start using it).
Toochain != SDK. I have a 180-line shellscript that builds a toolchain. That is fine for compiling bits of standalone code, but it's useless for writing homebrew until you have an SDK (i.e. a library).
Of course a fully legal SDK could be created. It's just, in my experience, exceedingly unlikely if people start using Sony's SDK all over the place. See my comment above: it's very hard to get people to contribute to and switch over to an open, legal project, when they can just keep using the illegal but convenient SDK that they've been using until now. Sometimes someone decides to manually decompile the SDK, producing a "homebrew" library that is still a derivative work and, thus, still illegal (this happened on the GameCube and got "adopted" for the Wii; we only discovered that half of libogc was copied from Nintendo's SDK when it was too late and everybody was locked in).
Thing is, as I said, there's a perfectly good PS3 OS (Linux) with multiple truly open and fully legal SDKs, and which will just with higher-than-GameOS-app privileges when using the USB exploits (I'm working on a Linux bootloader of this kind). Therefore, people should concentrate on that instead of just playing Sony Authorized Developer and using the silly illegal SDK.
Microsoft already felt the pain, because the Xbox 360 hypervisor got owned by the same exact hole. It would almost be the same instruction-by-instruction identical bug were it not for the fact that the 360 is a PowerPC system and this is an x86_64 hole. Yes, they, too, used a 32-bit compare to check the system call humber, then indexed into the array using the full 64 bits, exactly the same bug that caused this Linux hole.
Of course RSX is unlocked, otherwise games wouldn't be able to access it. I'm not proposing reenabling the old locked-down OtherOS support, but rather simply replacing lv2 with Linux. The underlying hypvervisor API is the same. There are few differences between OtherOS and GameOS other than what you're running as lv2 (Linux or GameOS) and what lv1 will let you do (RSX and flash and the like, or not).
Of course they are. There is no open SDK available for the GameOS APIs, nor is there likely to be one for quite a while, if at all. And as far as I know there is no.pkg file packer yet either.
Slashdot Mirror
Stack smashes are easy. The PS3 exploit is a complex interaction with multiple noncompliant USB devices and is still not fully understood. All we know is a pointer to a function pointer gets overwritten with attacker-controlled data (the end of a USB descriptor) and the rest is history, but the circumstances leading to that overwrite are much more complicated than your average exploit. And none of it has anything to do with the stack (as far as we know anyway!). Phiren claims it's a heap overflow overwriting a malloc boundary tag, but I'm not convinced.
RNA retroviruses, such as HIV.
They do have a nice render farm. Not exactly huge, but also not exactly the kind of thing Joe Average Film Maker can afford to put together.
I did mention that (some of) the headers contain code, especially graphics-related ones that include static inline functions or #define macros for speed.
And even then, just merely using a library's headers and dynamically linking to it is definitely not as clear cut as you make it sound. Just ask the FSF; at least they swear and maintain that (dynamically or statically) linking against GPLed code means you are bound by the terms of the GPL. At some point, a library interface ceases to be a "database of facts". Consider a complex library that defines a multitude of interfaces including data structures. Just because there is no executable code doesn't mean the interface and its structures and their definitions cannot be considered a creative work.
This is a moot point, though, because code compiled with the Sony SDK statically links in their libraries.
The copyrightable material is created in the form of source code, but that copyright status is maintained through any transformations, manual or automated. Binary code has as much creative input as the source code it is produced from.
I haven't checked the details, but I'm willing to bet that the physical differential signaling levels used for PCIe (LVDS) and SAS/SATA are pretty similar. As long as they at least kept the transmit/receive pairs in the same place, I bet that plugging in the wrong type of device will probably just cause error reports from the controller or at worst severely confuse the device and/or controller, but won't cause any permanent damage.
That's not how copyright works. Derivative works don't have to be in the same class or perform the same function as the original, they just have to be derivative.
Static linking doesn't work like that. Your final binary includes large chunks of the SDK inside it (for typical homebrew, the SDK portions are larger than the homebrew itself). And the addresses of those chunks of code change depending on how things get linked. It's the same output that you would get if you had the full source code of the SDK libraries and used it as part of your app, except you don't get to see or change that code. The end result, nonetheless, includes a fully relocated and linked version of it.
I don't see why there would be an issue enforcing a license which is clearly being violated if you're not an authorized developer. Doing what you want with your own hardware is/should be a right, but you don't have the right to getting a convenient SDK for it.
They are, in fact, equivalent, in this case, as I've explained. This is how embedded SDKs work. This isn't new and applies to every console SDK and also pretty much every embedded SDK. It even applies to PC applications, just to a lesser extent: library code is usually dynamically linked, but header files are statically included, your program includes the compiler's support functions (e.g. floating point emulation where necessary, and general support routines such as function prologue and exception handling helpers). You also use the library's crt0 startup code. Again, these things come with licensing exceptions (e.g. libgcc comes with a linking exception) that we take for granted, but those licensing exceptions are still required.
Compiling code with a development system isn't like producing a data file with an application (e.g. making a document in a word processor). Software compilation always involves copying (sometimes large) parts of code from the SDK into your app.
Using prototype.js or jQuery on your Web application means you COPY them into your website and include them via script tags.
Now s/jQuery/SDK/ and s/Web application/game/ and s/script tags/static linking/. See what I mean?
(ignore the fact that you can include them from external URLs; this isn't an option on consoles. You have to pretend that instead of <script src=...> you actually copy and paste the entire thing into an inline <script> block)
There is no source, as the payload is a hacked (hex edited) version of the original PSJailbreak payload. All they did was change the string /dev_bdvd to something else, to break the functionality. All you need to do is get a hex editor and change those four characters back to bdvd.
Pretty much, yes. It's a special call that invokes special code to trigger the redirection. You can get rid of all of that and still keep the debug package patches and the unsigned code patch.
Compiling code against the SDK implies including SDK headers (which are considered copyrightable, especially for nontrivial ones; for example, lots of GPU code is inlined in headers for speed) and statically linking SDK libraries (this isn't a PC where most things are dynamically linked). Both of these clearly produce a derivative work.
Normally, PC SDKs and similar have redistribution licenses that cover the redistributable parts of the SDK. These licenses are often taken for granted, but they need to be there. Console SDKs have different licenses that only apply if you're an authorized developer with a license to use the SDK and who is publishing through the console manufacturer.
Of course, you can use Sony's SDK's compiler (which is a GCC fork) to build some app that doesn't use any of their libraries (careful though, you'll have to use -ffreestanding and -nostartfiles and -nostdlibs, otherwise you link in their crt0.o and libc!), and distributing that app would be legal, but this is a totally pointless exercise because you can trivially build a PowerPC GCC that does the same. The useful parts of the SDK are the headers and statically linked libraries.
Yes they are. Once you include SDK headers or link your application with the SDK libraries, it becomes a derivative work and for our intents and purposes equivalent to distributing portions of the SDK.
Most SDKs have special license provisions that allow this, which is common sense (otherwise the SDK would be useless). Those license provisions aren't as broad for console SDKs, nor do they apply if you aren't a legal user of the SDK to begin with. If you aren't an authorized Sony developer publishing your game through Sony, you aren't licensed to use or link with or distribute code built with the Sony PS3 SDK, as doing so means redistributing portions of said SDK, which is copyright infringement without a license.
Since I am interested in homebrew, not backups, I simply do not endorse or associate myself with tools that enable copies (legitimate or not).
There is no practical way to allow fair use backups while not allowing piracy. Therefore, as a homebrew developer, it's a hell of a lot easier to just stay away from the entire business of copying games. Would it be nice to be able to back up games? Absolutely. But I don't consider it essential, and involving yourself with it inevitable means associating yourself with piracy, which is something I think homebrew developers would do best to avoid.
Besides, it's not like backing up your games is an inherent expectation when buying a console. Everyone knows full well that the DRM restricts their rights. It's not our job to fully and completely crack every aspect of the DRM for every purpose; if you really dislike some aspect of the DRM, then you probably should've voted with your wallet and not have bought the system in the first place.
The proof is simply the device's marketing, which centers around running "backups", which even a stupid judge can understand is an euphemism for "pirate copies" most of the time. Even if you drink the "backups" kool-aid, it's still letting you bypass the technical protection measures (whether for legitimate use or not) and, therefore, it's a circumvention device.
The issue is that courts aren't going to care that legal uses exist if those legal uses are used by a tiny minority of people. Every circumvention device, by definition, has legal uses (since customers are being denied their rights by the DRM), but circumvention devices are still mostly illegal. If your legal uses are broad enough to have significant weight (see e.g. iPhone jailbreaks), then you might get an exemption or similar. Another option is to remove the functionality that enables the actual copying to attempt to get the "circumvention device" label slapped on whatever is developed to piggyback on your hack and ultimately play copied games. This is what I'm advocating.
It shouldn't, but it is. Personally, I think it'd be great if the whole "circumvention device" nonsense went away and instead companies focused on cracking down on actual copiers. However, the current US law is what it is, and it isn't going to magically change now. Devices to "jailbreak" (horrible term, blatantly ripped from the iPhone scene, does not really apply here) your PS3 with the ability to play copied games are not currently legal in the US, whether you plan to exercise that ability to pirate games or not.
Whether the software explicitly enables or partially enables copying games (i.e. includes functionality specifically for this purpose) instead of merely doing so as a side effect of a general security bypass hack (e.g. simply enabling copied PSN games by merely allowing unsigned code) can be legally significant.
iPhone jailbreaks are in little legal trouble lately, among other reasons, because none of them have any functinoality related to pirating App Store apps. Those apps can be ripped, decrypted, and installed as any unofficial app, but the jailbreak itself includes no functionality to aid in this process; it is a mere consequence of the ability to install unsigned apps. Contrast this with including code that is specifically and exclusively designed to play copied Blu-Ray games.
Nope, I just have a lot of practical experience with the group of people who collectively insist that they're "backing up their games", and how the vast majority are obviously pirates. Most are either outwardly pirating (and they just substitute the term 'backup' because it's cool, but otherwise outwardly acknowledge illegally downloading and copying games), or don't try very hard to hide it.
It's also common sense. Do you honestly believe that there's even a tiny chance that most people hacking their consoles aren't doing it for piracy? Especially with the PS3, where there has been an explosion of people who are out to buy or make a PSJailbreak clone, even though there's just about no useful homebrew for it yet.
The problem is that all of the code is still there and working, they just changed a single string to subtly break it. Right, this "does the job", but it makes it so ridiculously easy to reenable that it could be considered similar to, say, openly selling a game console cheat device that just happens to enable loading copies if you hit the right button combination, load the right hacked configuration file, or enter the right magic cheat code. It's still dodgy.
And heck, I know full well that the people responsible for these open clones (at least the original PSGroove and PSFreedom authors) are perfectly capable of rewriting the code to yank out the piracy parts (and save a lot of space; for technical reasons, the payload is pretty constrained), especially seeing as it's been analyzed pretty thoroughly by now. This is why I'm advocating at least taking the (not much) time to make an independently compilable reimplementation that entirely does away with all of the redirect code, instead of just trivially disabling it.
I would normally prefer the term "the copied-game-loading code", which is more correctly neutral, but sometimes I get so irritated by all the lying smartasses who use the term "backup" as a thin veil (and thus discredit the minority of people actually legitimately backing up their own games) that I feel like using a term that is biased the other way just to make it blatantly obvious what most people end up using the code for.
Specifically, I'm talking about the Blu-Ray redirection patches which are still present in the PSGroove code (which is just a version of the PSJailbreak code hex-edited to trivially break, but not remove, this functionality). In other words, the PSGroove is technically a pirated PSJailbreak (not that I care about commercial game copying products getting copied, but there are legal implications to basing your stuff too much on a piracy device). It's a lot cleaner if you just take the required core concept of the exploit and develop an open product around it that shares nothing more than what is strictly necessary with the original.
Torrenting it and then distributing code compiled with it both are, which is what everyone who is using the Sony SDK did. Copyright infringement is copyright infringement. If Sony didn't grant you a license to use the PS3 SDK, then you aren't allowed to legally use it.
The DMCA exceptions are revised every 3 years and the recent phone jailbreaking exception singles out phones and does not apply to consoles. The primary purpose of the device (the PSJailbreak) that started this is piracy, and this is what the vast majority of people using the device and its clones are doing. Even though the homebrew clones are trying to move away from it, currently, they still share quite a bit of the piracy code. Worse, currently, all installable PS3 homebrew is developed with the leaked Sony SDK, which, in and of itself, is also piracy.
I'm not saying Sony's case is a good idea, but they have a much better case than Apple would right now.
Personally, I'm working on using the PSJailbreak exploit (not any of its code, payload, patches, or functionality) to run a fully original payload that will eventually boot Linux as GameOS (with access to the 3D hardware, but otherwise similar to OtherOS). In order to avoid legal trouble, I would recommend that open source PS3 hack authors do something along similar lines and distance themselves from the original game-loading payload and the Sony SDK (and even GameOS). If you do that, then you seriously cut down on the number of things that Sony's lawyers can grab on to for a case.
My €.02.
Nope, it wouldn't suffice for SSL sites.
That makes no sense. After Sony pulled OtherOS, anyone who cared to continue hacking just didn't update and continued hacking on the older versions.
The OtherOS RAM glitching attack was impractical and had nothing to do with piracy, and yet Sony were stupid enough to not only care, but direct attention towards GameOS which is precisely the target that would be ripe for piracy exploits.
Sony already blew it by pulling OtherOS. If the PS4 is less open, then, as usual, chances are it will be attacked earlier and by more dedicated homebrew hackers, and it will lead to piracy earlier. The PS3 was the most open system this generation, and also the one that lasted the longest without piracy. This isn't a coincidence. Sony can either learn the lesson and open up the PS4, or not do so and end up like all the others (somewhat outdated table).
The USB exploit was discovered and used by a piracy company/manufacturer, but it is practically guaranteed that they built off of the then-early homebrew hacks for its development (the geohot glitching exploit and xorloser's xorhack toolkit, to name a couple), even though the final product was condensed down to a piracy device. These early homebrew hacks started off as a response to Sony pulling OtherOS from the Slim and ballooned after Sony illegitimately pulled OtherOS from all existing consoles.
The PS3 has doubtlessly been under attack from would-be piracy companies since its release. Given the timing involved, I think we can safely say that the PSJailbreak piracy device wouldn't have happened had Sony not pulled OtherOS and prompted homebrew hackers to start breaking into the system, paving the way for thorough analysis. Though admittedly in this case the PSJailbreak developers did more of the work than you'd normally expect (usually, homebrew is well on its way before piracy companies start using it).
Toochain != SDK. I have a 180-line shellscript that builds a toolchain. That is fine for compiling bits of standalone code, but it's useless for writing homebrew until you have an SDK (i.e. a library).
Of course a fully legal SDK could be created. It's just, in my experience, exceedingly unlikely if people start using Sony's SDK all over the place. See my comment above: it's very hard to get people to contribute to and switch over to an open, legal project, when they can just keep using the illegal but convenient SDK that they've been using until now. Sometimes someone decides to manually decompile the SDK, producing a "homebrew" library that is still a derivative work and, thus, still illegal (this happened on the GameCube and got "adopted" for the Wii; we only discovered that half of libogc was copied from Nintendo's SDK when it was too late and everybody was locked in).
Thing is, as I said, there's a perfectly good PS3 OS (Linux) with multiple truly open and fully legal SDKs, and which will just with higher-than-GameOS-app privileges when using the USB exploits (I'm working on a Linux bootloader of this kind). Therefore, people should concentrate on that instead of just playing Sony Authorized Developer and using the silly illegal SDK.
Microsoft already felt the pain, because the Xbox 360 hypervisor got owned by the same exact hole . It would almost be the same instruction-by-instruction identical bug were it not for the fact that the 360 is a PowerPC system and this is an x86_64 hole. Yes, they, too, used a 32-bit compare to check the system call humber, then indexed into the array using the full 64 bits, exactly the same bug that caused this Linux hole.
Of course RSX is unlocked, otherwise games wouldn't be able to access it. I'm not proposing reenabling the old locked-down OtherOS support, but rather simply replacing lv2 with Linux. The underlying hypvervisor API is the same. There are few differences between OtherOS and GameOS other than what you're running as lv2 (Linux or GameOS) and what lv1 will let you do (RSX and flash and the like, or not).
Of course they are. There is no open SDK available for the GameOS APIs, nor is there likely to be one for quite a while, if at all. And as far as I know there is no .pkg file packer yet either.