Toggle sidebar

Hacking Atmosphere-NX - Custom Firmware in development by SciresM

  • Thread starter Thread starter Waze0613
  • Start date Start date
  • Views Views 2,792,778
  • Replies Replies 9,395
  • Likes Likes 93
well wait here there is a big difference between emunand on a playstation system , on the ps3 it would be possible with Cobra and Non Cobra Firmwares or Rebug , but the PS4 is running with WebkitExploits , and i am more than sure that we cant mess with the nand on the PS4 , because if that would be the case we already had a cobra like CFW
 
Will it be possible to install game updates with CFW?
I never thought I would miss game updates this much..
 
Loke said:
Will it be possible to install game updates with CFW?
I never thought I would miss game updates this much..
Click to expand...
With emuNAND, you will probably have access to the eShop and access to game updates, yes.
 
Natehaxx said:
but only on the OFW not with CFW and now with KASLR crap i am sure we cant even move behind 5.0
Click to expand...

Hu? Why would that matter with emunand and TX in place? Basically the system is fully busted from a security point of view as soon as you have that in place, no? I can't see why we shouldn't be able to integrate any future fw changes into the CFW?
 
  • Like
Reactions: Subtle Demise
If KASLR raises time investment on every firmware release - *cough* (I might see a way out of this for Nintendo.. ;) :/ ).
 
Lacius said:
Why would that be the case? An up-to-date emuNAND should play nicely with the eShop, CFW or not.


That probably won't matter.
Click to expand...
Isn't the prerequisite for emuNAND usually having cfw anyway? From what I can tell these updates should have no real affect on cfw and emuNAND, instead the patches are more mitigations to prevent future exploits.
 
TheCyberQuake said:
Isn't the prerequisite for emuNAND usually having cfw anyway? From what I can tell these updates should have no real affect on cfw and emuNAND, instead the patches are more mitigations to prevent future exploits.
Click to expand...

emuNAND is not really needed at all. You could simply install the CFW on the NAND without emuNAND. It is just a convenience to have, in order to easily stay up to date on the OFW, so that you can for example play online without worry or delay (since the CFW release will be trailing behind at least a bit).

But yes, very little impact of these updates on the firmware development, mostly mitigation.

EDIT: Sorry I miss-read: Is a CFW needed for emuNAND? Well a custom hypervisor is. But not any other parts.
 
Last edited by Onibi,
Mitigation might be enough to prevent "current" CFW.

Logic goes like this. Lets say we "own" 5.0.0 then 5.0.1 comes out, encrypted - with new keys, lets say we can decrypt it (the container), but not own it, the moment 5.0.2 comes out - with new keys, we might have a problem.

Emunand might still be possible (not sure) - but if they can detect it in any way, they could ban online accounts, which can serve as a disincentive as well.

Also - never underestimate mitigation. :) If time to exploit rises from one week to one month - it can be game over for "most recent CFW" dreams. Nintendo can afford to release a new firmware - with new keys, every month.

And believe me, the motivation curve for hackers changes radically at that point.. ;)
 
Last edited by notimp,
notimp said:
Mitigation might be enough to prevent "current" CFW.
Click to expand...
To delay the time until the CFW is as new as the OFW, absolutely, I agree :)

notimp said:
Logic goes like this. Lets say we "own" 5.0.0 then 5.0.1 comes out, encrypted - with new keys, lets say we can decrypt it, but not own it, the moment 5.0.2 comes out - with new keys, we might have a problem.
Click to expand...

This will not work on a fully broken system. See, we can just install the OFW and use either the bootrom bug or the TZX/emuNAND to grab anything the update contains. If new keys are deployed, so be it? We can grab them. We have full control over the lowest level of the system. Even lower then the update.

notimp said:
Emunand might still be possible (not sure) - but if they can detect it in any way, they could ban online accounts, which can serve as a disincentive as well.
Click to expand...

This will be one of the more interesting and fun things to do. Hiding the emuNAND :) You are completely right thou!

notimp said:
Also - never underestimate mitigation. :) If time to exploit rises from one week to one month - it can be game over for "most recent CFW" dreams. Nintendo can afford to release a new firmware - with new keys, every month.

And believe me, the motivation curve for hackers changes radically at that point.. ;)
Click to expand...

That's why I think emuNAND with an OFW is likely to be used whenever the CFW is not up to date (or just to be safe). Sure the CFW may trail, but the CFWs aim shouldn't be online play anyway. As a developer, it wouldn't be any main concern of mine to enable CFW online play. (I wouldn't work against it, but I wouldn't care to make it work either. Just use the OFW.)

I am pretty sure Nintendo will try to mitigate the Hell out of this to not allow online play of backups and cheating. And I am sure it will work somewhat well. Good for them :)
 
Last edited by Onibi,
This will not work on a fully broken system. See, we can just install the OFW and use either the bootrom bug or the TX/emuNAND to grab anything the update contains. If new keys are deployed, so be it? We can grab them. We have full control over the lowest level of the system. Even lower then the update.
Click to expand...
This is the key point.

Lets say we have low level owned. We say allow official key, and 000000 (our key). At that point we can run anything on the system we want.

New Firmware comes in. Changes official key. We can see that, probably also see key - key is used to start the new kernel. Kernel is hardened against all known attacks.

We try to look at its behavior, it uses memory address space randomization. We have a hard time doing that. :) Even though we own the system, we cant read new keys (for other stuff) in the kernel.

This might be a difficult problem. :) Probably solvable, but the timeframe is important too. :)

I think this is how it works - but I'm not an expert. Just someone proficient at logic. ;)
 
Last edited by notimp,

Site & Scene News

Go to forum More news

Popular threads in this forum