34w ago - Following up on the recent explanation by
marcan42 (scroll down), today PlayStation 3 and Vita hacker
wololo has added some clarification of his own below.
To quote from his blog (linked above):
PS3 Blown open, Scene chaos, LV0 keys Leaked and Working!
Leaks, chaos and drama have been something common, and on the heels of the PSVita chaos comes the PS3s turn with both good and bad news. This event is so huge that it will completely change the PS3 hacking scene and leave Sony in the wake.
Sony will be turning in their graves today as the PS3 has been basically blown wide open thanks to other events leading up to that. In the wake of this leaves Sony in huge trouble and mostly exhausted due to the amount of progress the hacking scene has made on their devices especially with the recent Psvita PSP EMU kernel exploit.
It’s been absolute chaos in the PS3 scene for the last few days and fair enough to say has been chaotic over the last few years. Ill break down what happened and what this means for the developers and users, keep reading...
Background Information
The similarity in events is extremely blatant but its started a little over two years ago when the first piracy-enabled firmware and USB dongle combo named the “PS3Jailbreak” was released. The release nuked a weakness in the PS3′s simple USB protocols. This in return created a hole allowing the OS to be patched that furthermore allowed content to run from the HDD. In the aftermath the group fail0verflow allowed people to encrypt files in a mirror system that replicated Sony s methods.
Of course this lead to tons of piracy and eventually Geohot’s public release of the “metldr” root key. Sony got really mad in short and decided to bring the ban hammer down on Geohot who has yet to be heard from recently. Sony found a way to protect their system by fixing everything in the system with the 3.60 firmware update. The jailbreak was patched, the USB exploit patched and left the system somewhat secure, until now in association with the new PS3 4.30 firmware update.
So what happened?
The jerks, which is an understatement, that have been behind the PS3 dongle business will always be hated and trashed constantly and the recent stunt from the people behind the BlueDiscCFW team just put a nail in the coffin. A hacking group called “The Three Musketeers,”, in short, had the Lvl0 keys which were leaked. The Three Musketeers were not going to release the keys because of the known outcome of doing so.
The Chinese hacking team “BlueDiscCFW,” somehow got a hold of the keys and planned to charge money for users who wanted the exploit. Its disgusting they would do that and The Musketeers realized this. With that in mind, The Three Musketeers tried to immediately stop BlueDiscCFW’s profiting from the LV0 exploit, The Three Musketeers released the LV0 custom firmware free to the public. The funny part is the BDCFW was taken down immedietly. The Three Musketeers released a statement on it saying
“You can be sure that if it wouldn’t have been for this leak, this key would never have seen the light of day, only the fear of our work being used by others to make money out of it has forced us to release this now.”
It was a two faced leak and is oddly similar to that Sam Jordam incident or Linux hack. They then released a full announcement and statement on the matter:
As this was a group effort, we wouldn’t normally have lost a word about it
ever, but as we’re done with PS3 now anyways, we think it doesn’t matter
anymore [http://pastie.org/4462324]. Congratulations to the guy that leaked
stuff, you, sir, are a 1337 haxx0r, jk, you’re an xxxxxxx. Try this bytes...
– [erk=CA7A24EC38BDB45B98CCD7D363EA2AF0C326E65081E0630CB9AB2D215865878A]
– [riv=F9205F46F6021697E670F13DFA726212]
– [pub=A8FD6DB24532D094EFA08CB41C9A72287D905C6B27B42BE4AB925AAF4AFFF34D
41EEB54DD128700D]
– [priv=001AD976FCDE86F5B8FF3E63EF3A7F94E861975BA3]
– [ctype=33] ...and be amazed.
People should know that crooked personalities are widespread in this so called ‘scene’. Some people try to achieve something for fun together and make the wrong decision to trust others and share their results with them, but ofc there got to be the attention seeking fame whre that has to leak stuff to feel a little bit better about him-/herself.
Now the catch is that it works like this in every ‘scene’, just that in others it usually doesn’t come to light. The only sad thing is, that the others who worked on this won’t get the attention they deserve because they probably want to remain anonymous (also they don’t care about E-fame <3).
PS: This is neither about drama nor E-fame nor ‘OMG WE HAZ BEEN FIRST’, we just thought you should know that we’re disappointed in certain people. You can be sure that if it wouldn’t have been for this leak, this key would never have seen the light of day, only the fear of our work being used by others to make money out of it has forced us to release this now. [-The Three Musketeers]
What does this mean?
With the release of the LV0 keys mean, eventually, having all the keys available. The LV0 is not patchable, which is to say there is nothing at all Sony can do to fix this. The final bullet in the chamber as hit Sony hard. What actions they will take are not known, but if things continue in the scene I can guarantee they will be pushing the date of the PS4 closer as new hardware is really all they can do. Sony already moved all the loaders.
The only other option would be to put the loaders in bootldr, but that isn’t possible since bootldr is locked to being console specific and is impossible to update. Behind LV0 is just bootldr, which is encrypted with specific console keys. This leak will in time lead to a 4.25 CFW which can be installed on mostly any PS3 even on Slims and the recent new slim models. Keep in mind that fail0verflow released metldr private keys like I said above. Well, surprise, metldr is loaded by lv0ldr, even on 3.60+.
The leak contains a private key, it’s the string after PRIV=. The greatest part is that the key isn’t tied up to a specific firmware. The problem with 3k model Playstation3 consoles is that they have a new LV0 version named lv0.2, which means new keys for the loader. What this means is that consoles which are able to downgrade to 3.55 can install 4.25 CFW even if they’re on 4.25 OFW. The bad news incorporated with this is that 3K and higher consoles’ LV0 keys are static, they are not console specific.
Sony can change LV0 with a new firmware update. But, bootldr is per console and is the way of decryption for LV0. If we have bootldr then the console is wide open and a CFW could be made to work on any console. Bootldr cannot be changed or denied unless there is a hardware change.
Even if we had bootldr then anyone with a downgradable console could have a CFW firmware. Whoever has bootldr and wanted to leak it would bring the greatest massacre and ban-hammer of all time by any company ever, I can garuntee whoever releases it will have no where to run or hide so it would of course need to be anonymous to highest level with no traces to be found. Bootldr is something that’s way more protected and valuable than metldr.
Closing Statement
This is the beginning of a very long and heavily scheduled future of the PS3 hacking scene. The release of the LV0 key means that any system update released by Sony going forward can be decrypted fully with no effort. Sony has no cards in this game. As of today LV0 is now decrypted for ever until the end of time.
There is a lot of reverse engineering to get the decrypted loaders from it since Sony had changed a lot of security algorithms to protect these loaders inside LV0 however, rest assure every PS3 developer is hot on the news of everything going on. No one will be able to find 4.XX LV1, LV2_kernel, AppLDR keys inside the decrypted LV0 so there would need to be an investigation regarding how Sony store these keys right now.
Already hard at work Multiman and Rogero have released new CFW along with other developers working hard. Rogeros new CEX 4.21 CFW FFA was pulled however due to bricking issues, so be alert to that. With this we may in some vary valuable information, in a way, that’ll help get some much needed help in also hacking the Vita but that’s not something to be confirmed. Although in given time more information and understanding on this will come, so stay tuned.
Update: Here is another update from
wololo (via wololo.net/2012/10/25/clarifying-the-confusion-on-the-ps3-development/), to quote:
Clarifying the confusion on the PS3 development
If you read my post about the LV0 keys being leaked recently then you know it could be a lot to take in and hard to understand. Hopefully this will help clear up everything.
Marcan, who is a valuable asset of the Wii and PS3 hacking scene has made some posts that will help clear the air on things, it helps clarify and break things down even more than what I had previously said in the original article both in technicality and in simplicity. I’ve bolded the important parts that you should pay attention to in his answers.
More Technical Information
“The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it).
This second-stage bootloader verifies lv0. Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.
However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the “second root” in the PS3′s bizarre boot process) using a different exploit (we replicated this, although our exploit might be different).
At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr’s brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.
Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a “sandboxed” SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don’t have control over the rest of the software.
For the exploit that we knew about, it would’ve required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would’ve taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control – the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.
Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony’s epic failure).
The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn’t just decide to brick them all...), and those old PS3s now have no remaining seeds of security that aren’t known.
This means that all future firmwares and all future games are decryptable, and this time around they really can’t do anything about it. By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s.
From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn’t mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn’t have any security leg to stand on now.
It does not mean that current firmwares are exploitable. Firmware upgrades are still signed, so you need an exploit in your current firmware to downgrade. Also, newer PS3s presumably have fixed this (probably by using newer bootldr/metldrs as trust roots, and proper signing all along).”
They are indeed the bootldr keys (I was able to decrypt an lv0 with them). Consider this confirmation that the story is not fake.
Can this be used to sign binaries to run homebrew on OFW PS3s (ala the PSP key leak)? Are those private keys sufficient to sign homebrew software such that they will run in unmodified firmware?
No. The keys are used for two purposes: chain of trust and chain of secrecy. The compromise of the keys fully compromises the secrecy of the PS3 platform permanently, as you can just follow the links down the chain (off-line, on a PC) and decrypt any past, current, or future firmware version. Current consoles must be able to use any future firmware update, and we now have access to 100% of the common key material of current PS3s, so it follows that any future firmware decryptable by current PS3s is also decryptable by anyone on a PC.
However, the chain of trust can be re-established at any point along the line that can be updated. The chain of trust is safely rooted in hardware that is near impossible to modify (i.e. the CPU’s ROM and eFuse key). The next link down the chain has been compromised (bootldr), and this link cannot be updated as it is specific to each console, so the chain of trust now has a permanent weak second link. However, the third link, lv0, can be updated as it is located in flash memory and signed using public key crypto.
This allows Sony to secure the entire chain from there onwards. Unless you find a vulnerability in these updated links, you will not be able to attack them directly (applications, e.g. homebrew software, are verified much further down the chain). The only guaranteed way to break the chain is to attack the weak link directly, which means using a flash writer to overwrite lv0. Once you do so, the entire chain collapses (well, you still need to do some work to modify every subsequent link to turn off security, but that is easy).
If you have old firmware, you have at least some other weak links that, when compromised, allow you direct access to break the bootldr link (replacing lv0), but if you run up to date firmware you’re out of luck unless you can find a weakness or you use hardware.
Old PS3s are now in the same boat as an old Wii, and in fact we can draw a direct comparison of the boot process. On an old Wii, boot0 (the on-die ROM) securely loads boot1 from flash, which is securely checked against an eFuse hash, and boot1 loads boot2 but insecurely checks its signature. On an old PS3, the Cell boot ROM securely loads bootldr from flash, which is securely decrypted and checked using an eFuse key, and then bootldr loads lv0 but checks its signature against a hardcoded public key whose private counterpart is now known.
In both cases, the system can be persistently compromised if you can write to flash, or if you already have code execution in system context (which lets you write to flash). However, in both cases, you need to use some kind of high-level exploit to break into the firmware initially, particularly if you have up-to-date firmware. It just happens that this is trivial on the Wii because there is no game patch system and Nintendo seems to have stopped caring, while this is significantly harder on the PS3 because the system software has more security layers and there is a game patch system.
Breaking it down into simple and easy to understand words
Since Marcan’s answers can be a bit difficult to digest, I’ve broken them up into the form of questions and answers with the special help of ViRGE on this. This will clear alot of it up for those less technical.
Q: What exactly has been recovered?
A: The keys used by bootldr to decrypt/verify lv0, and by reversing the process the private keys used by Sony to sign lv0. If we consult our handy 3.60+ chain of trust diagram, we can see that bootldr is at the very root of the chain of trust, with lv0 being the first module it loads.
Q: So what can we do with the lv0 signing key?
A: In short, we can use it to decrypt lv0, modify it to patch out any lv0 security checks, and resign it with a legitimate key that bootldr will accept. With the chain of trust broken and lv0 no longer enforcing the security of the modules that it controls, we can then start modifying lv1ldr, lv2ldr, appldr, isoldr, etc to patch out their security checks and add CFW functionality.
Q: Can Sony “fix” this like they did for the 3.55 exploit?
A: No. With 3.55 the keys metldr used to verify its dependent modules were recovered. So Sony simply stopped using the now-insecure metldr and started using bootldr (which was still secure) to load.. Sony doesn’t have any more secure modules like bootldr left so like I said in my original post they have no options and cant fix anything; without getting too technical, we now have the keys to every “common” hardware module that is able to decrypt Sony-signed modules. The only thing left are the modules that use per-console keys, which are useless for booting common firmware (which must be decryptable by every PS3)
Q: So bootldr is fixed in hardware?
A: Correct. Like metldr, bootldr cannot be software updated by Sony. It’s hard-coded in hardware. As a reminder, bootldr/metldr themselves can’t be exploited, but because of the keys we have recovered we can make them load anything we want, nullifying whatever security they provide.
Q: What about future firmwares?
A: Good news! We can decrypt those too. Sony can use various coding tricks to make the process more difficult (this is called obfuscation), but they can’t stop us by using keys. We will always be able to decrypt lv0, and as long as we can figure out how to navigate lv0 we can figure out how to decrypt and modify its dependent modules. For those of you that follow Sony hardware this is much like how the earlier PSPs were hacked. So we can always decrypt the firmware and will be able to create newer CFWs as long as we can get past any obfuscation by Sony.
Q: So the PS3 is utterly and completely broken?
A: To an extant yes, debatable but unlike the 3.55 hack we have mostly everything needed. Sony will never be able to re-secure existing consoles.
Q: What about consoles running firmware newer than 3.55?
A: Because all “old” consoles use the same keys to verify modules like lv0, at a minimum we can decrypt, patch, and resign the firmware. The problem is that we need a way to convince the PS3 to flash our modified firmware.
With 3.55 and below that was easy enough to do because of the keys recovered, but 3.56 and later change that so that flashing is more complex than just using the recovered keys. This isn’t an insurmountable problem – hardware flashers will always work – but for easy software flashing we need to find new exploits in the PS3 software stack to convince OFW consoles to flash CFW.
Q: What about newer consoles?
A: So there’s the real problem. Remember how we said bootldr and metldr are fixed in hardware? Sony can create new hardware, and update those modules in the process. By using new hardware in conjunction with new firmware for that hardware, Sony could completely change the keys used to secure the system. Without getting too technical, all of this progress comes from the fact that Sony was sloppy and did a poor job of implementing their security on earlier consoles, which is what lead to the first keys being leaked.
Sony could always issue new hardware with new keys and a fixed security system at which point we’d be completely locked out of that new hardware. It’s entirely possible they’ll do this (if they haven’t done so already), so much like the PSP we’re going to end up with a limited number of consoles that have hardware-based flaws that can be exploited. Of course we then found new ways of exploiting the PSP anyhow, and ultimately were able to exploit every PSP made in one way or another.
If you are on anything higher than 3.55 it doesn’t mean you are out, there are ways to downgrade if your model is one thats able, otherwise you are just not able to do anything right now until more dev work is done. So sit tight and hold on. Again stay tuned, more info and news will be definitely coming.
In summary, all future PS3 games will be crackable and CFW versions of all future firmware can be made. However, 3.56+ (3k Slim and 4k Super Slim) ship with Bootldr2 which we do not have keys for, still require hardware to downgrade and of course many newer PS3s remain protected from downgrading.
From
KaKaRoToKS (via playstationlifestyle.net/2012/10/23/daily-reaction-the-ps3-hack-the-ethics-the-impact-guest-starring-kakaroto/) to quote:
"
Seb: I’d like to think that I’ve been pretty open minded about hacking in previous interviews I’ve held, but you have to wonder what ‘The Three Musketeers’ were thinking when they shared the keys with other people. You can’t trust anyone on the internet, and it was sadly naive to believe that one of the people they gave it to wouldn’t try to sell it. Now, they’re probably worrying whether Sony is looking for them, preparing to sue them.
I’m all for being able to do what you want with your own technology, you bought it, do what you want with it. But, just like when I buy a pen I shouldn’t pour the ink all over my face, individuals need to be responsible for what they do with the tech. Hack it, crack it, turn it into a toaster, whatever – but if letting people know what you did and how you did it could lead to piracy, then don’t release it, don’t share it.
Youness: There is no denying that there is a part of responsibility in what is being done by the hackers, but to be honest, you can’t really predict what will happen in the future, and you can’t be responsible for what others do. Don’t forget that this release of the lv0 keys doesn’t add such a huge advantage to the hacking community, but the keys were never meant to be released, because it was still somehow opening up potential piracy which is something the true hackers are absolutely against.
The secret of the keys was well guarded, but somehow it got leaked (after many many months), and the reason for the release was to prevent some greedy company (dongle manufacturer) from profiting from the piracy it could have enabled. In the end, it happened, it’s unfortunate, but I wouldn’t sweat (or rejoice) too much over it. The release wasn’t about the fame or the “being first”, it was about countering an immoral act.
Dan: Even though there is much debate about what rights consumers have regarding what they are able to do with the products they purchase, the ability to do something does not always give a free pass to the action. As such with the release of the keys, the ability to break into a device you own is, in my opinion, very much your right, but the knowledge and ramifications of the information become that person’s liability. As it would be for someone who owns a car and decides to modify it, if it became unsafe to be around, the responsibility would fall on its owner.
With all that said, the problems that fell on Sony in the wake of the eventual hacks are something that will be remembered forever. The cost to Sony, and their consumers, is not something that will likely ever be measured. So is there a point where the ability to do something does not outweigh the potential ramifications?
Youness: Well, of course, the ability to do something does not give you a free pass to do it. However doesn’t that go both ways? The ability to remove Linux from the PS3 does not give Sony the right to do it, and in the end, when you look at the facts, that’s what initiated the whole thing. There is always a need for a moral compass. Sometimes it’s about whether or not the benefits outweigh the negatives, but sometimes there are some undeniable rights that cannot be tossed out the window.
As an example, you can’t remove freedom of expression of the press if you think it might cause a civil war… Yes, the benefits (freedom of expression) do not outweigh the negatives (potential death of a population), but it doesn’t mean you can suddenly silence everyone and use that as an excuse. The car example that Dan gave is a good one, and sure, you can mod your car all you want, as long as you don’t take it on the road from the moment it doesn’t pass regulations.
What I am mostly angry about is when I see people playing the “devil’s advocate” thinking about the loss to Sony, loss from piracy, and loss from emulators and homebrew. I do want to see them complaining about all those things, as long as I see them also complain about the loss to the consumer.
Loss of Linux support (which comes with loss of your data), loss of the right to class action sue, loss of hundreds of games legally bought online because “your account was banned”, loss of your game collection when your PS3 goes for repair and suddenly gets replaced by an inferior model that doesn’t have backward compatibility, loss of money after being forced to buy the same game multiple times. Why isn’t anyone complaining about those issues just as hard as they complain about piracy and homebrew. Both, in my eyes should be defended equally, don’t you agree?
Seb: Look, I’m all against Sony having removed Linux, and if we did DR back then we could have had you on and joined in on your complaints. But what’s done is done, it’s bad, but two wrongs do not make a right. Just because Sony was a dick, doesn’t mean we should all be dicks back. Previous PS3 hacks allowed people who had a PS3 that had Linux to revert back to older FW, they had the opportunity. This hack serves little purpose than to open the floodgates to more piracy.
Again, loss of an account or paying double for a game sucks, but it’s very rare. You talk about weighing up the positives and negatives, but that’s an example of where a small amount of people will benefit from having their accounts back, but a huge amount of developers and publishers will suffer, and then, ultimately, gamers who end up getting less games.
I do complain about those issues, and perhaps I should more, but taking matters into your own hand, no matter the collateral, isn’t the right way. In the end, nobody wins.
Youness: Well, some are trying to get back at Sony for what they did, and usually they don’t get very far because when hate or corruption or whatever is your drive, then you simply won’t succeed. But I agree with you, two wrongs don’t make a right. Sometimes though I wonder, when you get 10 wrongs and you still don’t do anything about it, how likely will there be a 11th wrong?
I know you don’t like it when that bad stuff happens and that’s why I like PSLS, you do defend both sides. But I’d like to correct one misconception you seem to have.. no, this new hack won’t open any floodgates. It serves absolutely no purpose for anyone who wasn’t already on a custom firmware, so it won’t add any new users into the ‘piracy world’.
As for your comment about “no matter the collateral”, don’t worry, I can reassure you that that’s not the case! This release is just one of many things that could be released, it happened to be leaked, but there are other hacks, information, exploits that could lead to piracy that simply get buried because of this collateral. Even these lv0 keys, as I said will have a very minimal impact (if any) on the piracy, but they were not released for the simple case of “maybe, just maybe, it could help piracy, even though I can’t think of any way for it to”, so the hackers behind it prefered to stay on the safe side rather than be sorry later.
Don’t always assume that the hackers are always trying to hack everything for their own selfish reasons. Being a true hacker means you have skills, and skill comes with experience, and with experience comes the moral compass that we spoke about. As far as I know, all the piracy enabling hacks were dirty little hacks made by young and irresponsible teenagers who were looking for their 15 minutes of fame. It is unfortunate though that they used the legitimate work of others as a stepping stone.
How long has it been since there was any significant development in the PS3 hacking scene? Almost 2 years now! It’s not because it became impossible, it’s simply because we have access to homebrew and Linux, so there is no need to hack it further (or release new hacks). It’s not a fight about “who will win”, it’s a simple matter of “are we happy about it”.
Another huge reason why the hacking scene has dried up is because of the piracy, not all hacking scenes are like this (think of the iPhone or Android hacking), but the PS3 (and generally Sony followers) scene is one of the worst in terms of self-entitled kids and piracy, and most of the hackers felt that it does not deserve their attention anymore. Tired of the drama and the whining and the piracy, most of us have decided to retire.
Dan: While none of this is to simply place the blame on anyone, or any single group. It is more the discussion about how to stand up for the things you believe, “irregardless” of what other might think. Although, as an online community that connects the world together in a way that generations could not have imagined. We must at some point realize. much like the ancient proverb from Uncle Ben goes: “With great power, comes great responsibility.”
So regardless of what side of this gray line you fall, the simple fact that at the end of the day – the consumer will always be hit the hardest. So when a corporation, or developer wrongs its user base, what lengths we go to defend our rights should always keep in mind the just how far your reach can really go in this modern era."
From
JuanNadie comes a guide on
How to Dump the PS3 Bootldr /
PS3 BOOTLDR.BIN Dump by
zecoxao
Wow... such hostility against me just cause I said that one my future projects was trying to adapt the btldr exploit to hardware so we can hack (ie run unsigned code) on all consoles. I think I deserve the opportunity to explain myself before you start doubting me.
That means releasing the btldr exploit (which it patchable) before the others devs can even check if its remotely possible but it is the only way to get redemption so let's start...
DUMPING THE BOOTLDR
As you know the bootldr is one of the two loaders that are signed per console and it was the only part of the system that haven't been hacked.
Once you load it the same way as metldr (via SigNotify) it would start requesting different addresses that we don't control. You can take a look on my user page to the dma sequence that it produces.
As you see it access a lot of different addresses and we don't have control of any of them so the first objective was to control the input/output.
The sandbox
The objective was to redirect the flows of data to our controlled buffers so we know what is written or read. To achieve that a driver was created.
This driver performs two functions:
- the first is creating lv1 peek/poke using the patched lv114 that comes with OtherOs++ and other CFW.
- the second is reserve a block of consecutive memory that would be used as an HTAB.
The SPU is told to use our HTAB which in turns redirects to our user buffers. To get the physical address... the user pages are locked on memory and then using an old trick found by geohot their real address is retrieved.
At this point we have control of what the SPU reads BUT if consecutive small accesses are done we have no control if we want to change something in between.
The first exploit
I'm calling this an exploit but actually is a bad implementation of a feature cause it should be disabled on isolation. The feature is called the MFCLSACMP. Basically is a register on the spu that is checked before doing a dma op. If the source/target address on the SPU is inside the mask defined by this register then dma is stopped and an interruption is reported. Until this interrupt is cleared the dma is not started.
Great, so we control what it reads and when it is read... the first objective was achieved total control of the I/O. That is what you can see on my user page on wiki.
However this all so allowed me to find the biggest problem on using the booldr as an oracle... the config ring.
The config ring is a series of bits that syscon sends to the cell before during the power up... On this cell implementation the config ring is accessible from inside the spu as a read once channel. So unless I could find a way to refill the channel the bootldr couldn't be used as oracle. Even worse at this point I didn't know how the config ring was read (although an undocumented channel was on top of the list).
I spent a couple weeks trying to figure the problem. Finally I posted the log on the wiki looking for help. Obviously some approach. We exchanged info. I gave then the tools and they gave me means of validating my hypothesis (those on the log)
We worked a lot of time on this. Remember that I was trying to get an oracle not an exploit so filling the config was a must... several thing were tried but none worked.
After a month or so I started checking other projects while thinking of what to do. Then after several months I decided to try to exploit it instead of using it.... given the log the entry point was clear...
The bootldr exploit
If you see the log you'll see a lot of data exchanging between the spu and the syscon. graf had described it on his bible so it was known... but the log also said that the data was read twice once to read the header and once to read header + data.
On the header was a variable length. So I decided to change the len between both reads.... didn't work until i corrected also the chksum... and then BINGO! unexpected behavior... a possible exploit was found.
The advantage of this exploit is that it gave us a lot of points to test. The info was shared and two of us friendly raced one against the other to find the correct possibility.
I won the race of finding the execution point although I lost the one for dumping. The winner was command 0x20 which is an info message... casually the config error message... so their own protection had given us the bootldr.
That's the story of the exploit... it was then decided that I got the ultimate decision of releasing the exploit and any of us could leak the keys... however they asked me too hold it until SONY has reacted to the dex conversion and I told them that I would not release them until I got the appldr keys by myself.
I suppose they passed the keys to others and them at some point the keys probably arrived to EXETrimAll and N0DRM (I don't think they exploited trublue...). Meanwhile i was in the middle of my holidays and when I come back they were releasing non-stop so I didn't see that it was necessary to leak them.
Unfortunately they also leaked to a scoundrel that sell the key to discblu. That forced some one that have the key to make it public.
You said that I'm angry cause someone leak the key... nope. I was angry with discblu... and with some hacker that reappeared just to say that he already knew how to do it. As you can see the method is completely software and does not use the signature bug (except for installing the cfw... but then all the apps need to credit them). If you persist I'll tell you that this can also be done on a 3.15 with geohot pulse exploit.
The code: http://www.sendspace.com/file/wvknol
I have attached the code of a working version for latest exploitable slim. I know that also works on other version but I don't know which ones. It is only valid for NOR consoles cause it expects a full NOR flash as one of the parameters.
It has two programs. One is a kernel module so it must be load with insmod.
The second its a user program that takes as parameter the speID (i recommend using 0 that is normally enabled), the flash file and a debug file with the buffers. the actual dump is WRITTEN TO DUMP.BIN
If the exploit worked you should see the text "Interrup". If it didn't try modifying line 799 correctPacket(0x40, 0, 0); by incresing the first parameter (0x40). Thats the len that is send on the second read.
The dump is shifted by as a side effect of the bug. For me it was 0x800 bytes... but others got different result. The start function must be at 0x400 once shift is corrected
BTW the code is ugly and there is a lot of data that is not used so if someone has questions please ask me (on this or other ps3 related things)... I'll be available until sunday... then I'll definitely leave. Now I'll explain my idea for the hardware solution.
Improving the exploit
THE FOLLOWING IS ALL THEORETICAL AND IT WILL PROBABLY NOT WORK (I'M NOT A HARDWARE EXPERT AND THAT'S THE MOST DIFFICULT PART)
In this case the objective is not dumping the bootldr but get code execution. Using an small payload a program will be copied to spu. That program will just copy a patched unencrypted lv0 to the memory and tell the PPU that code was loaded successfully.
By achieving that we would have full control of the system. Our patched lv0, will load an original lv1ldr (required to get the ATA keys) which will load an original lv1 but before giving control to level1 our level0 will patch it so we still have control. Same with lv2 and vsh.
As I said basically the bug consist of changing the response len between the first read and the second. That is easily done if you control the buffer where the data is located (exploitable consoles). But we want to do this before anything is loaded
So we need to change the comm between syscon and cell before any software outside the cell is loaded... the only option is a hardware interceptor. This hardware will intercept the communications and change it so the exploit is triggered (This is called a man in the middle attack). The payload will be sent as part of the 0x20 command reply... if the bug is trigger properly we know that our payload will start around 0x3E010.
In addition to this I recommend adding a second flash chip that will contain the patched firmware. That will allow the user to go from patched to official with a switch
As you see the device I propose is not a drm device... it actually triggers an exploit similar to the ODE device that whats announced (BTW that is perfectly done with the info that glevand posted).
The questions is: Is all of this possible?... well from the software part I'm pretty sure but I don't know if the hardware can be build or if the cost will be too much.
In any case if it is possible, there is enough info on this post to make it...
Unfortunately there is also a enough info to patch the bug (if they didn't already). However it would only be patchable on factory...
Finally, from
redcfw: As I know, many peoples working hard for the scene, some release it, some not.
FF13 CFW fix - 100% exploited TrueBlue LV2, with VM step tracing bldr1&2
act.dat&rif algo - someone has got it few years ago - from PSP
Here is some step debugging code:
loc_19C: # CODE XREF: scePspNpDrmInitFromGameIdMs4+94j
jal sceNpDrmVerifyAct
move $a0, $a1
bltz $v0, loc_288
move $a1, $v0
jal sceNpDrmVerifyRif
move $a0, $s0
bltz $v0, loc_288
move $a1, $v0
lui $a2, (KeyMac_2310 >> 16)
addiu $a1, $sp, 0x40+var_30
addiu $a0, $s0, 0x40
la $a2, KeyMac_2310
jal DecryptDataWithHashMac
# End of function RotR4Byte
# Segment type: Pure data
.data # .rodata
KeyHash_22D8: .word 0x9D9E3D07, 0x2F3BFDA8, 0x2E931863, 0x64A657F8 # 0
# DATA XREF: scePspNpDrmInitFromGameIdMs4+15Co
HashVrAct_22E8: .word 0xAB02762, 0xB06F8502, 0x67870841, 0x18A0E019 # 0
# DATA XREF: sceNpDrmVerifyAct+8o
# sceNpDrmVerifyAct+14o ...
.word 0xB9EE9132, 0xBF6A736E, 0xE90EF781, 0xDE0D1B16 # 4
.word 0x1A7626B0, 0x5BC87BFF # 8
KeyMac_2310: .word 0x5E4B7DDA, 0x534F9A49, 0x4AA1C1B1, 0x3B448474 # 0
# DATA XREF: scePspNpDrmInitFromGameIdMs4+C4o
# scePspNpDrmInitFromGameIdMs4+D4o
KeyVdoHash_2320:.word 0xCD5B20E8, 0x30355711, 0x16ED8DBE, 0xF66A9382 # 0
# DATA XREF: sceNpDrmVideoKey_driver_77743584+DCo
# sceNpDrmVideoKey_driver_77743584+E0o
aFlash2Act_dat: .ascii "flash2:/act.dat"<0>
# DATA XREF: sceNpDrmVideoKey_driver_77743584+48o
byte_2340: .byte 0x5E # DATA XREF: DecryptWithPsID+8o
# DecryptWithPsID+40r
4.20 4.30 key algo
.unknown:00028C0C ai r3, sp, 0x20 ; dst ;next cbc key
.unknown:00028C0C ; 0x40030000000000000000000000000 //??
.unknown:00028C10 ai r86, sp, 0x30
.unknown:00028C14
.unknown:00028C14 loc_28C14:
.unknown:00028C14 brsl lr, readch73
.unknown:00028C18 lr r4, r80 ; key
.unknown:00028C1C lr r5, r81 ; key len
.unknown:00028C20 brnz r3, loc_28C5C
.unknown:00028C24 ai r6, sp, 0x20 ; r6 src
.unknown:00028C28 il r7, 0xA ; r7 len
.unknown:00028C2C lr r3, r86 ; r3 dst
.unknown:00028C30 brsl lr, sha1_hmac_buffer
.unknown:00028C34 lr r4, r82 ; r4 src
.unknown:00028C38 lr r5, r83 ; r5 len
.unknown:00028C3C brnz r3, loc_28C5C
.unknown:00028C40 lr r6, r86 ; r6 key
.unknown:00028C44 lr r3, r85 ; r3 dst
.unknown:00028C48 lr r8, r84 ; r8 iv
.unknown:00028C4C il r7, 0x80 ; r7 128 bit
.unknown:00028C50 brsl lr, AesCbc128Decrypt
.unknown:00028C54 il r2, 0
.unknown:00028C58 brz r3, loc_28C60
Code:
u8 erk_hkey[] = { 0xAA, 0xF6, 0x5A, 0x91, 0xEC, 0x37, 0x2C, 0x69, 0x09, 0x69, 0x09, 0x0F, 0x59, 0xE5, 0x3C, 0x3E };
u8 iv_hkey[] = { 0x66, 0xBC, 0xB4, 0x17, 0xD1, 0x4A, 0x2B, 0x59, 0x26, 0x40, 0x80, 0x1C, 0x11, 0xB7, 0xB4, 0x9B };
u8 erk_iv[] = { 0xA5, 0x79, 0x8C, 0x25, 0x43, 0x13, 0xBC, 0x54, 0x16, 0x95, 0x1E, 0x24, 0xEA, 0xD3, 0xC9, 0x85 };
u8 iv_iv[] = { 0x2F, 0xF2, 0x36, 0x15, 0x2A, 0x47, 0x76, 0xDA, 0xD3, 0x9B, 0x50, 0x92, 0x44, 0xE8, 0xF5, 0xC2 };
u8 ch73[0xa] = {?? }; //?? your can dump it with an appldr patch!!!
u8 key341s[] = { 0x54,0x6B,0x2F,0xF3,0xFE,0x21,0x6E,0xD2,0xBA,0x86,0x5C,0x79,0x36,0x81, 9,0xA1, //; erk secret NPKEY
0x5F,0x2B, 0xD,0x23,0xC2, 3,0x13,0x54,0xB1,0xF6,0xF3,0x6B, 0xF,0xDB,0x4D,0x46 ,// erk
0x9B,0x87,0x1D,0x64,0x14,0xB8,0xAA,0xCE,0x54,0x2C,0x18,0x10, 0xA,0xC2,0x18,0x93 };// iv
u8 key341[] = { 0xBB,0x4D,0xBF,0x66,0xB7,0x44,0xA3,0x39,0x34,0x17,0x2D,0x9F,0x83,0x79,0xA7,0xA5,
0xEA,0x74,0xCB,0xF,0x55,0x9B,0xB9,0x5D,0xE,0x7A,0xEC,0xE9,0x17, 2,0xB7, 6,
0xAD,0xF7,0xB2, 7,0xA1,0x5A,0xC6, 1,0x11,0xE,0x61,0xDD,0xFC,0x21,0xA,0xF6};
u8 keyd[0x30];
void key430()
{
AES_ctx ctxErk, ctxIv;
u8 ch73shErk[0x10], ch73shIv[0x10];
hmac_sha1(ch73,0xa,erk_hkey,0x10,ch73shErk,16); //16 = 128bit hash
AES_set_key(&ctxErk, ch73shErk, 128);
AES_cbc_decrypt_iv(&ctxErk, key341s, keyd, 0x20, erk_iv, 1);
hmac_sha1(ch73,0xa,iv_hkey,0x10,ch73shIv,16); //16 = 128bit hash
AES_set_key(&ctxIv, ch73shIv, 128);
AES_cbc_decrypt_iv(&ctxIv, key341s+0x20, keyd+0x20, 0x10, iv_iv, 1);
} From
Naehrwert via pastie.org/5089738 (attached below).
From
zadow28: I have been looking at the pastie too. and translate the pastie into an openssl command
Test command
Zadow ~/ssl
$ openssl aes-128-cbc -d -in all.bin -out decall.bin -nosalt -K ( TEST ERK) -iv (TEST IV ) -p -nopad
key=8EACAB1950A79147DB391A88FCF9DE1B097C5667DBB6F6E1FEAA4980AB4E7E1B
iv =ACA5B101EC4B9497691632917E555472
Code:
Zadow
@zadow
-PC ~/ssl
$ openssl aes-128-cbc -d -in all.bin -out decall.bin -nosalt -K 8EACAB1950A79147DB391A88FCF9DE1B097C5667DBB6F6E1FEAA4980AB4E7E1B -iv ACA5B101EC4B9497691632917E555472 -p -nopad
key=8EACAB1950A79147DB391A88FCF9DE1B097C5667DBB6F6E1FEAA4980AB4E7E1B
iv =ACA5B101EC4B9497691632917E555472
you have to have an all.bin that is the 48 hex bytes of the erk+riv (the scrampled one)
then in the command -K 8EACAB1950A79147DB391A88FCF9DE1B097C5667DBB6F6E1FEAA4980AB4E7E1B -iv ACA5B101EC4B9497691632917E555472 is where you put you test erk and iv, if it decrypts right the decall.bin would match the one you put in the all.bin its an little time comsuming to insert all the hex. and dont know but got an hunch that it could be DEADBEEF evilsperm
u8 ch73[] = { 0x40, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; //?? i dont get it yet
000365E0 AA F6 5A 91 EC 37 2C 69 09 69 09 0F 59 E5 3C 3E ��7,i.i..YÕ<>
000365F0 66 BC B4 17 D1 4A 2B 59 26 40 80 1C 11 B7 B4 9B f+�.ÐJ+Y&@Ç..�ø
00036600 A5 79 8C 25 43 13 BC 54 16 95 1E 24 EA D3 C9 85 Ñyî%C.+T.ò.$�+à
00036610 2F F2 36 15 2A 47 76 DA D3 9B 50 92 44 E8 F5 C2 /=6.*Gv+��-
00036620 FF FF FF FF 00 00 00 00 00 00 00 01 00 00 00 01 ****............
00036630 FF FF FF FF 00 00 00 07 00 00 00 06 00 00 00 02 ****............
00036640 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................
00036650 FF FF FF FF 00 00 00 30 00 00 00 20 00 00 00 20 ****...0... ...
00036660 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ................
00036670 00 00 00 00 FF FF FF F0 00 00 00 00 00 00 00 00 ....****........
00036680 62 7C B1 80 8A B9 38 E3 2C 8C 09 17 08 72 6A 57 b|���8Ò,î...rjW
00036690 9E 25 86 E4 00 00 00 00 00 00 00 00 00 00 00 00 ×%å�......... See the last two lines
00036680 62 7C B1 80 8A B9 38 E3 2C 8C 09 17 08 72 6A 57 b|���8Ò,î...rjW
00036690 9E 25 86 E4 00 00 00 00 00 00 00 00 00 00 00 00 ×%å�.........
that is some off the metadata that is in every signed file by sony eboots etc. but not in the appldr from 3.55-infact it shouldent be in any decrypted file. so got some thing with the keys.
u8 ch73[] = { 0x40, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 its simply saying the firmware version in this case 4.3 by the way i already tried these keys myself, didnt work you have to reverse it longer back. Thats why i use the openssl to test.
From
BuC-ShoTz: long time no talk bro. i've found the same thing, the 1st and the 3rd key seems like it decrypts the erks, the 2nd and 4th keys decrypt the rivs. i'm still trying to confirm its aes, and also the CypherMode, now if that is a sha1 hash in redcfw's post, i'm inclined to think its aesctr, for instance retail pkg's use aesctr. now that i look at more at redcfw's post, is ch73 the resulting hmac?, looks good recfw, thank you.
From
zxz0O0: According to recfw's code, hmac is in ch73 (which was [u8 ch73[] = { 0x40, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; //?? i dont get it yet] before he edited his post) and result stored in
u8 ch73shErk[0x10] and ch73shIv[0x10];
Tried with lv2ldr, result is:
3da56b9b349048917aa86511f9651f122ac5a6756b6899fc828b305b5cd0ddda88d4d3a54efaa744e2fee5de543da0d7
Update to rogero 3.55 Cfw and if you can find the hex to program that then it will work. Thanks....
If possible can someone tell me more about that?
DO NOT TRY THIS!
NP local license handling (C) 2012 by flatz
• SCE Header:
Magic 0x53434500 [OK]
Version 0x00000002
Key Revision 0x0010
Header Type [SELF]
Metadata Offset 0x000003F0
Header Length 0x0000000000000900
Data Length 0x00000000000C9D00
• Metadata Info:
Key 3F 1D 99 53 C6 80 C7 C0 46 54 C2 7C 03 95 A8 91
IV 85 CD 91 78 31 2F 9E 05 7E E7 95 9A 22 AB B9 F7
• Metadata Header:
Signature Input Length 0x00000000000008A0
unknown_0 0x00000001
Section Count 0x00000006
Key Count 0x0000002E
Optional Header Size 0x00000030
unknown_1 0x00000000
unknown_2 0x00000000
• Metadata Section Headers:
Idx Offset Size Type Index Hashed SHA1 Encrypted Key IV Compressed
000 00000900 0004BDB2 02 00 [YES] 00 [YES] 06 07 [YES]
001 00058600 00003F14 02 01 [YES] 08 [YES] 0E 0F [YES]
002 0005C514 00000000 02 02 [YES] 10 [YES] 16 17 [NO ]
003 0005C514 00000000 02 03 [YES] 18 [YES] 1E 1F [NO ]
004 0005C514 00000000 02 04 [YES] 20 [YES] 26 27 [NO ]
005 0005C610 000006C0 01 03 [YES] 28 [NO ] -- -- [NO ]
• SCE File Keys:
00: 86 78 6D 6F F5 E2 DD BB 3C F2 CD EA 21 D6 94 36
01: C5 FA BC 79 00 00 00 00 00 00 00 00 00 00 00 00
02: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
03: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
04: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
05: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
06: 88 42 7C AC 9E 94 CB 67 A6 42 A9 B6 5F 19 47 A7
07: F7 62 B4 AD 5A 81 48 97 BD 89 B5 5B 80 1C B2 DB
08: 55 A6 D7 D7 AA FD DC AB 53 EB C6 2D 91 45 16 98
09: 57 D4 82 E6 00 00 00 00 00 00 00 00 00 00 00 00
0A: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
0B: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
0C: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
0D: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
0E: 88 42 7C AC 9E 94 CB 67 A6 42 A9 B6 5F 19 47 A7
0F: F7 62 B4 AD 5A 81 48 97 BD 89 B5 5B 80 1C B2 DB
10: 45 54 9C 94 65 67 74 CE 58 7B D6 2B 6B 40 8E 4D
11: 19 C0 E6 84 00 00 00 00 00 00 00 00 00 00 00 00
12: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
13: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
14: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
15: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
16: 88 42 7C AC 9E 94 CB 67 A6 42 A9 B6 5F 19 47 A7
17: F7 62 B4 AD 5A 81 48 97 BD 89 B5 5B 80 1C B2 DB
18: 45 54 9C 94 65 67 74 CE 58 7B D6 2B 6B 40 8E 4D
19: 19 C0 E6 84 00 00 00 00 00 00 00 00 00 00 00 00
1A: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
1B: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
1C: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
1D: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
1E: 88 42 7C AC 9E 94 CB 67 A6 42 A9 B6 5F 19 47 A7
1F: F7 62 B4 AD 5A 81 48 97 BD 89 B5 5B 80 1C B2 DB
20: 45 54 9C 94 65 67 74 CE 58 7B D6 2B 6B 40 8E 4D
21: 19 C0 E6 84 00 00 00 00 00 00 00 00 00 00 00 00
22: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
23: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
24: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
25: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
26: 88 42 7C AC 9E 94 CB 67 A6 42 A9 B6 5F 19 47 A7
27: F7 62 B4 AD 5A 81 48 97 BD 89 B5 5B 80 1C B2 DB
28: 7F D0 D9 E9 5F DC 81 F3 1D C9 B1 B7 C4 D2 16 0F
29: 45 46 67 E6 00 00 00 00 00 00 00 00 00 00 00 00
2A: 76 28 F8 FE 36 3B 9A C1 B7 2F E1 78 AD 3F D5 19
2B: 3B 55 FD FB 26 15 B7 12 6F E2 40 9A 0D 35 7A CB
2C: 95 C3 59 2C CE 7F 1A 79 E1 46 05 5C 10 B2 CA 59
2D: 26 08 5E DE CA BA 19 B2 5E BF 2C 1D 59 6D 3D CD
• SELF Header:
Header Type 0x0000000000000003
App Info Offset 0x0000000000000070
ELF Offset 0x0000000000000090
PH Offset 0x00000000000000D0
SH Offset 0x000000000005C610
Section Info Offset 0x0000000000000290
SCE Version Offset 0x0000000000000390
Control Info Offset 0x00000000000003A0
Control Info Size 0x0000000000000070
• Application Info:
Auth-ID [Lv2diag FW Stuff]
Vendor-ID [normal]
SELF-Type [Application]
Version 03.60
• SCE Version:
Header Type 0x00000001
Present [FALSE]
Size 0x00000010
unknown_3 0x00000000
• Control Info
Type Flags
Size 0x00000030
Next [TRUE]
Flags 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
• Control Info
Type Digest
Size 0x00000040
Next [FALSE]
Digest 1 62 7C B1 80 8A B9 38 E3 2C 8C 09 17 08 72 6A 57
9E 25 86 E4
Digest 2 5E 0D 82 DF 70 AB FF 26 E0 87 67 C6 16 CF 9B 89
0E CB E5 1B
• Optional Header
Type Capability Flags
Size 0x00000030
Next [FALSE]
unknown_3 0x0000000000000000
unknown_4 0x0000000000000000
Flags 0x000000000000001B [ 0x01 0x02 REFTOOL DEBUG ]
unknown_6 0x00000001
unknown_7 0x00000000
• Section Infos:
Idx Offset Size Compressed unk0 unk1 Encrypted
000 00000900 0004BDB2 [YES] 00000000 00000000 [YES]
001 00058600 00003F14 [YES] 00000000 00000000 [YES]
002 0005C514 00000000 [NO ] 00000000 00000000 [YES]
003 0005C514 00000000 [NO ] 00000000 00000000 [YES]
004 0005C514 00000000 [NO ] 00000000 00000000 [YES]
005 00000000 00000004 [NO ] 00000000 00000000 [NO ]
006 00000000 00000000 [NO ] 00000000 00000000 [NO ]
007 00000000 00000040 [NO ] 00000000 00000000 [NO ]
• ELF64 Header:
Type [EXEC]
Machine [PPC64]
Version 0x00000001
Entry 0x00000000000D2778
Program Headers Offset 0x0000000000000040
Section Headers Offset 0x00000000000C9640
Flags 0x00000000
Program Headers Count 0008
Section Headers Count 0027
SH String Index 0026
• ELF64 Program Headers:
Idx Type Offset VAddr PAddr FileSize MemSize PPU SPU RSX Align
000 LOAD 00000000 00010000 00010000 000B40C0 000B40C0 X-R --R --- 00010000
001 LOAD 000C0000 000D0000 000D0000 00009544 000160B0 -WR -WR --- 00010000
002 LOAD 000C9544 00000000 00000000 00000000 00000000 --R --- --- 00010000
003 LOAD 000C9544 00000000 00000000 00000000 00000000 -WR --- --- 00010000
004 LOAD 000C9544 00000000 00000000 00000000 00000000 -WR -WR -WR 00010000
005 TLS 000C8BC4 000D8BC4 000D8BC4 00000004 00000088 --R --- --- 00000004
006 PARAMS 00000000 00000000 00000000 00000000 00000000 --- --- --- 00000008
007 PRX 000B4080 000C4080 000C4080 00000040 00000040 --- --- --- 00000004
• ELF64 Section Headers:
Idx Name Type Flags Address Offset Size ES Align LK
000 0000 NULL --- 00000000 00000000 00000000 0000 00000000 000
001 000B PROGBITS -AE 00010200 00000200 0000002C 0000 00000004 000
002 001F PROGBITS -AE 00010230 00000230 000ABC28 0000 00000008 000
003 0011 PROGBITS -AE 000BBE58 000ABE58 00000024 0000 00000004 000
004 0017 PROGBITS -AE 000BBE7C 000ABE7C 000003A0 0000 00000004 000
005 0025 PROGBITS -A- 000BC21C 000AC21C 00000030 0000 00000004 000
006 0039 PROGBITS -A- 000BC24C 000AC24C 00000074 0000 00000004 000
007 0049 PROGBITS -A- 000BC2C0 000AC2C0 00000004 0000 00000004 000
008 0056 PROGBITS -A- 000BC2C4 000AC2C4 00000004 0000 00000004 000
009 0063 PROGBITS -A- 000BC2C8 000AC2C8 00000004 0000 00000004 000
010 0071 PROGBITS -A- 000BC2CC 000AC2CC 00000084 0000 00000004 000
011 007B PROGBITS -A- 000BC350 000AC350 00000004 0000 00000004 000
012 0089 PROGBITS -A- 000BC358 000AC358 00007D28 0000 00000008 000
013 0091 PROGBITS -A- 000C4080 000B4080 00000040 0000 00000004 000
014 00A5 PROGBITS WA- 000D0000 000C0000 00000058 0000 00000004 000
015 00AC PROGBITS WA- 000D0058 000C0058 00000028 0000 00000004 000
016 00B3 PROGBITS WA- 000D0080 000C0080 00000004 0000 00000004 000
017 00B8 PROGBITS WA- 000D0088 000C0088 000017F0 0000 00000008 000
018 00C5 PROGBITS WA- 000D1878 000C1878 00000074 0000 00000004 000
019 00D4 PROGBITS WA- 000D18F0 000C18F0 00000E78 0000 00000008 000
020 00DA PROGBITS WA- 000D2768 000C2768 00005790 0000 00000008 000
021 00DF PROGBITS WA- 000D7EF8 000C7EF8 00000CCC 0000 00000008 000
022 00E4 PROGBITS WA- 000D8BC4 000C8BC4 00000004 0000 00000004 000
023 00EB NOBITS WA- 000D8BC8 000C8BC8 00000084 0000 00000004 000
024 00F1 PROGBITS WA- 000D8C50 000C8C50 000008F4 0000 00000008 000
025 00F7 NOBITS WA- 000D9548 000C9544 0000CB68 0000 00000008 000
026 0001 STRTAB --- 00000000 000C9544 000000FC 0000 00000001 000
sadly that don't just take a clever person, that takes a clever person that is actually interested in doing it, and not afraid of any consequences. for all we know it could have already been done.
Hope is a great thing, its free and you can have as much of it as you want.
Sent from my GT-I9100 using Tapatalk 2.
What it effectively means is now that it can all be decrypted there is the possibility that someone will find out how the fw and ps3 gos about the verification of per console keys etc. and then copy the process, and make a new cfw that will update on ofw above 3.55.
it don't mean it will happen , it just means it could be possible if someone is smart enough to work it out. or at least thats how i understood it, ive been wrong before though. what is more likely is. now you'll just get a 4.31 cfw that installs only on 3.55 or below.
I bet theres a hell of a lot of code to read for devs. look how many files theyve been given access too in just a few months. The PS3s life will have ended before anyone gets round to making cfw install above 3.55 ofw. I reckon the few people that probably could do it aint even working on it, (they have no need) and the rest wouldn't know where to start.
but like i say, I'm often wrong, and this is highly likely to be one of those times.
Please could someone enlighten me what you can do with this two? And priv-key is still missing? Or Could we we "just" decrypt the 4.31 update and make a new 4.31cfw installable on 3.55?
Thank you soo much