Hacking Discovered a METHOD for UPDATING outdated Games

[Deathscreton]

If he does not reply here is a link explaining the procsess: https://www.reddit.com/r/SwitchHacks/comments/759myu/the_eshop_and_cdn_explained_switch_edition/

Thank you kind sir! It does seem like he intends to explain, but I'm going to read this thread regardless.

 

[yardie]

youd have to be real dumb to have believed this

 

[Deathscreton]

youd have to be real dumb to have believed this

I just can't get over your casual responses and profile picture. I fucking die everytime.

 

[guily6669]

.......
Was apart of a team for Remote Play on all android devices for the PS4. Was able to play my PS4 on my S7 edge at a park with my PS4 at home.

You mean the one from XDA forum? It's a patched Sony remote app, I have no luck with it using my crap ADSL and crap router...

Even some PC remote apps still work better with lower latency and jitter than the PS4 remote from Sony.

Anyway I don't understand why don't you just post the method so ppl can try... I'm on 3.02 and wanted to update Zelda.

 

[Deleted-442439]

You mean the one from XDA forum? It's a patched Sony remote app, I have no luck with it using my crap ADSL and crap router...

Even some PC remote apps still work better with lower latency and jitter than the PS4 remote from Sony.

Anyway I don't understand why don't you just post the method so ppl can try... I'm on 3.02 and wanted to update Zelda.

It is confirmed fake, it is technically impossible, check the link I posted above, SciresM will give us the details for this exact situation.

 

[Leonidas87]

It is confirmed fake, it is technically impossible, check the link I posted above, SciresM will give us the details for this exact situation.

Speaking of SciresM if he wants to communicate on the subject I'm hear. Let him know.

 

[Sephirosu]

I'm hoping one of the main developers in the switch community to give me the go-ahead on releasing a how to.

I wanted to be sure when the info is released that everyone has the opportunity to benefit, say before the method is fixed for example.

Well technically a Dev (SciresM himself) said that it's impossible to do that so in a way it's kind of like saying "go ahead show me proof". Not trying to sound snarky btw. Just really curious how you did it when a Dev said it's impossible :x

 

[Deathscreton]

Speaking of SciresM if he wants to communicate on the subject I'm hear. Let him know.

He's literally here on the thread with us. All you have to do is message him, or post here as you've done.

At this point, you're at a crossroads. You've pissed off the main reader portion of GBATemp in a bait and switch tactic gone wrong, you've got a respected Dev calling you out on your shit with technical reasoning as to why you're bluffing, and you're stalling for time. I'm legitimately interested in what you have to say at this point.

 

[Biuz]

Speaking of SciresM if he wants to communicate on the subject I'm hear. Let him know.

I don't think he actually wants to talk with you.

 

[Leonidas87]

Well technically a Dev (SciresM himself) said that it's impossible to do that so in a way it's kind of like saying "go ahead show me proof". Not trying to sound snarky btw. Just really curious how you did it when a Dev said it's impossible :x

And if Scires is incorrect on his assumption, if he really did give his input what if my method allows for a 5.0.0 exploit using a similar method.

The video is timestamped on YouTube almost ready for public viewing. Making a second one as we speak.

Does everyone want the VIDEO????

Does everyone want to see my findings????

Stay glued to your seats ladies and gentleman.

Let SciresM know I'm sure he'd be interested.

 

[yardie]

And if Scires is incorrect on his assumption, if he really did give his input what if my method allows for a 5.0.0 exploit using a similar method.

The video is timestamped on YouTube almost ready for public viewing. Making a second one as we speak.

Does everyone want the VIDEO????

Does everyone want to see my findings????

Stay glued to your seats ladies and gentleman.

Let SciresM know I'm sure he'd be interested.

time to go the fck away man

 

[Mnecraft368]

And if Scires is incorrect on his assumption, if he really did give his input what if my method allows for a 5.0.0 exploit using a similar method.

The video is timestamped on YouTube almost ready for public viewing. Making a second one as we speak.

Does everyone want the VIDEO????

Does everyone want to see my findings????

Stay glued to your seats ladies and gentleman.

Let SciresM know I'm sure he'd be interested.

Ok then show us...

 

[SciresM]

Here's the high level overview of the "updating a game on your console" process:

• Your console contacts Nintendo to see if there is an update available. It does this by contacting the "sun" (System Update Notification? Also a dual pun with the "beach/ocean" theme the servers have this time) and "aqua" servers, to see what the current system update for online is, and the required system updates are to go online. That these are different servers is why the "grace period" exists -- aqua updates a few days after sun, typically, and so even though your console knows there is a system update available it will not make you update to go online until aqua says you must.
• Once your console decides that it is allowed to go online, it contacts the "dauth" server (Device Authorization) in order to get an OAuth token required to use all of the other online services. This authentication process requires your console pass both the system version and a hardcoded, per-firmware hex string (?system_version=%08x&client_id=%s). These are both validated to be correct in order for your console to get a token.
• Once your console is authenticated, it contacts "pushmo", Nintendo's server for push notifications, downloading [your device ID].json. This describes new things that your console should download (updates, etc). Pushmo validates the token that gets sent to it.
• If there's an update (or if your console has specifically requested to update a title), your console will begin downloading it.
• Your console will download the CNMT (CoNtent MeTadata -- it's the equivalent of a TMD for the 3ds, but stored inside of an NCA) for the update from the "atum" server.
• Your console will decrypt and parse the CNMT, which lists the other NCAs. If an update has previously been downloaded, it will download a number of "Delta" NCAs, which will describe how to transform the already downloaded NCA content into the new NCA content (Because updates will often share the same titlekey, this can lead to some minor bandwidth savings. However, when new masterkeys release, they typically change the titlekey to a new one which causes this to be kinda pointless. You win some, you lose some). If an update has not been previously downloaded, the plain NCAs for the new content will be downloaded.
• Your console will check the NCA headers to see what Rights IDs are required to play the update. Rights IDs are essentially "handles" to titlekeys -- every rights ID corresponds exactly to one titlekey, globally. Typically, there is one Rights ID per (title ID, master key revision) combination. I'll also observe that that's pointless because titlekeys get transformed by master key-derived data when decrypted *anyway*, so they don't actually need to change the Rights IDs, but whatever.
• Your console will request from the CDN the tickets for those Rights IDs -- first it will try to obtain a common ticket, and then if that fails it will try to obtain a "personalized" ticket from "ecs" (ECommerce Services). Once both the contents are downloaded, and the tickets are downloaded, the update is installed.

Cool, so that's the process. Let's see why this thread is not possible:

First, your console must decide for itself that it's allowed to go online. sun and aqua both require your console's unique client cert to talk to, and use SSL -- you would need to patch the SSL module to interfere with this process. But let's suppose that the author of the thread has done so, with some secret 4.1.0 hax that he has that I don't know about, for the sake of argument.

Your console must then successfully authenticate with the dauth server. This requires it to know secret information stored in sysmodule NSOs in the latest sysupdate. Thus, for you to do this, you would need to have both patched the SSL sysmodule to disable verification, and patched the system's authentication code to send the correct data and user agents. This would require you to have dumped the code for the latest system update. You'll understand, I hope, if I simply do not believe you have done those things.

If you've done that patching correctly, the rest of the process should go totally smoothly -- you'd run into problems with "ecs", but since all updates use common tickets you don't have to worry about that.

However, your process is not one you're claiming is based on secret 4.1.0 haxx. I do not believe you have developed the relevant system patches, nor that you've dumped the 5.x sysmodule code required to know the secrets you need to authenticate. Hence: this thread's claims are not possible.

 

[Leonidas87]

I wonder if Nintendo is waiting too lmfao

 

[MachRc]

 

[Biuz]

Here's the high level overview of the "updating a game on your console" process:

• Your console contacts Nintendo to see if there is an update available. It does this by contacting the "sun" (System Update Notification? Also a dual pun with the "beach/ocean" theme the servers have this time) and "aqua" servers, to see what the current system update for online is, and the required system updates are to go online. That these are different servers is why the "grace period" exists -- aqua updates a few days after sun, typically, and so even though your console knows there is a system update available it will not make you update to go online until aqua says you must.
• Once your console decides that it is allowed to go online, it contacts the "dauth" server (Device Authorization) in order to get an OAuth token required to use all of the other online services. This authentication process requires your console pass both the system version and a hardcoded, per-firmware hex string (?system_version=%08x&client_id=%s). These are both validated to be correct in order for your console to get a token.
• Once your console is authenticated, it contacts "pushmo", Nintendo's server for push notifications, downloading [your device ID].json. This describes new things that your console should download (updates, etc). Pushmo validates the token that gets sent to it.
• If there's an update (or if your console has specifically requested to update a title), your console will begin downloading it.
• Your console will download the CNMT (CoNtent MeTadata -- it's the equivalent of a TMD for the 3ds, but stored inside of an NCA) for the update from the "atum" server.
• Your console will decrypt and parse the CNMT, which lists the other NCAs. If an update has previously been downloaded, it will download a number of "Delta" NCAs, which will describe how to transform the already downloaded NCA content into the new NCA content (Because updates will often share the same titlekey, this can lead to some minor bandwidth savings. However, when new masterkeys release, they typically change the titlekey to a new one which causes this to be kinda pointless. You win some, you lose some). If an update has not been previously downloaded, the plain NCAs for the new content will be downloaded.
• Your console will check the NCA headers to see what Rights IDs are required to play the update. Rights IDs are essentially "handles" to titlekeys -- every rights ID corresponds exactly to one titlekey, globally. Typically, there is one Rights ID per (title ID, master key revision) combination. I'll also observe that that's pointless because titlekeys get transformed by master key-derived data when decrypted *anyway*, so they don't actually need to change the Rights IDs, but whatever.
• Your console will request from the CDN the tickets for those Rights IDs -- first it will try to obtain a common ticket, and then if that fails it will try to obtain a "personalized" ticket from "ecs" (ECommerce Services). Once both the contents are downloaded, and the tickets are downloaded, the update is installed.

Cool, so that's the process. Let's see why this thread is not possible:

First, your console must decide for itself that it's allowed to go online. sun and aqua both require your console's unique client cert to talk to, and use SSL -- you would need to patch the SSL module to interfere with this process. But let's suppose that the author of the thread has done so, with some secret 4.1.0 hax that he has that I don't know about, for the sake of argument.

Your console must then successfully authenticate with the dauth server. This requires it to know secret information stored in sysmodule NSOs in the sysupdate. Thus, for you to do this, you would need to have both patched the SSL sysmodule to disable verification, and patched the system's authentication code to send the correct data and user agents. This would require you to have dumped the code for the latest system update. You'll understand, I hope, if I simply do not believe you have done those things.

If you've done that patching correctly, the rest of the process should go totally smoothly -- you'd run into problems with "ecs", but since all updates use common tickets you don't have to worry about that.

However, your process is not one you're claiming is based on secret 4.1.0 haxx. I do not believe you have developed the relevant system patches, nor that you've dumped the 5.x sysmodule code required to know the secrets you need to authenticate. Hence: this thread's claims are not possible.

We finally got some reality on this clearly fake thread, peace.

 

[Admiral124]

Fuck off.

 

[Mnecraft368]

Here's the high level overview of the "updating a game on your console" process:

• Your console contacts Nintendo to see if there is an update available. It does this by contacting the "sun" (System Update Notification? Also a dual pun with the "beach/ocean" theme the servers have this time) and "aqua" servers, to see what the current system update for online is, and the required system updates are to go online. That these are different servers is why the "grace period" exists -- aqua updates a few days after sun, typically, and so even though your console knows there is a system update available it will not make you update to go online until aqua says you must.
• Once your console decides that it is allowed to go online, it contacts the "dauth" server (Device Authorization) in order to get an OAuth token required to use all of the other online services. This authentication process requires your console pass both the system version and a hardcoded, per-firmware hex string (?system_version=%08x&client_id=%s). These are both validated to be correct in order for your console to get a token.
• Once your console is authenticated, it contacts "pushmo", Nintendo's server for push notifications, downloading [your device ID].json. This describes new things that your console should download (updates, etc). Pushmo validates the token that gets sent to it.
• If there's an update (or if your console has specifically requested to update a title), your console will begin downloading it.
• Your console will download the CNMT (CoNtent MeTadata -- it's the equivalent of a TMD for the 3ds, but stored inside of an NCA) for the update from the "atum" server.
• Your console will decrypt and parse the CNMT, which lists the other NCAs. If an update has previously been downloaded, it will download a number of "Delta" NCAs, which will describe how to transform the already downloaded NCA content into the new NCA content (Because updates will often share the same titlekey, this can lead to some minor bandwidth savings. However, when new masterkeys release, they typically change the titlekey to a new one which causes this to be kinda pointless. You win some, you lose some). If an update has not been previously downloaded, the plain NCAs for the new content will be downloaded.
• Your console will check the NCA headers to see what Rights IDs are required to play the update. Rights IDs are essentially "handles" to titlekeys -- every rights ID corresponds exactly to one titlekey, globally. Typically, there is one Rights ID per (title ID, master key revision) combination. I'll also observe that that's pointless because titlekeys get transformed by master key-derived data when decrypted *anyway*, so they don't actually need to change the Rights IDs, but whatever.
• Your console will request from the CDN the tickets for those Rights IDs -- first it will try to obtain a common ticket, and then if that fails it will try to obtain a "personalized" ticket from "ecs" (ECommerce Services). Once both the contents are downloaded, and the tickets are downloaded, the update is installed.

Cool, so that's the process. Let's see why this thread is not possible:

First, your console must decide for itself that it's allowed to go online. sun and aqua both require your console's unique client cert to talk to, and use SSL -- you would need to patch the SSL module to interfere with this process. But let's suppose that the author of the thread has done so, with some secret 4.1.0 hax that he has that I don't know about, for the sake of argument.

Your console must then successfully authenticate with the dauth server. This requires it to know secret information stored in sysmodule NSOs in the sysupdate. Thus, for you to do this, you would need to have both patched the SSL sysmodule to disable verification, and patched the system's authentication code to send the correct data and user agents. This would require you to have dumped the code for the latest system update. You'll understand, I hope, if I simply do not believe you have done those things.

If you've done that patching correctly, the rest of the process should go totally smoothly -- you'd run into problems with "ecs", but since all updates use common tickets you don't have to worry about that.

However, your process is not one you're claiming is based on secret 4.1.0 haxx. I do not believe you have developed the relevant system patches, nor that you've dumped the 5.x sysmodule code required to know the secrets you need to authenticate. Hence: this thread's claims are not possible.

And now, mods close the thread.
Thanks for clearing that up @SciresM

 

[Kioku]

I'm starting to question everything I knew. For what? I'm not quite sure.

 

[Leonidas87]

Here's the high level overview of the "updating a game on your console" process:

• Your console contacts Nintendo to see if there is an update available. It does this by contacting the "sun" (System Update Notification? Also a dual pun with the "beach/ocean" theme the servers have this time) and "aqua" servers, to see what the current system update for online is, and the required system updates are to go online. That these are different servers is why the "grace period" exists -- aqua updates a few days after sun, typically, and so even though your console knows there is a system update available it will not make you update to go online until aqua says you must.
• Once your console decides that it is allowed to go online, it contacts the "dauth" server (Device Authorization) in order to get an OAuth token required to use all of the other online services. This authentication process requires your console pass both the system version and a hardcoded, per-firmware hex string (?system_version=%08x&client_id=%s). These are both validated to be correct in order for your console to get a token.
• Once your console is authenticated, it contacts "pushmo", Nintendo's server for push notifications, downloading [your device ID].json. This describes new things that your console should download (updates, etc). Pushmo validates the token that gets sent to it.
• If there's an update (or if your console has specifically requested to update a title), your console will begin downloading it.
• Your console will download the CNMT (CoNtent MeTadata -- it's the equivalent of a TMD for the 3ds, but stored inside of an NCA) for the update from the "atum" server.
• Your console will decrypt and parse the CNMT, which lists the other NCAs. If an update has previously been downloaded, it will download a number of "Delta" NCAs, which will describe how to transform the already downloaded NCA content into the new NCA content (Because updates will often share the same titlekey, this can lead to some minor bandwidth savings. However, when new masterkeys release, they typically change the titlekey to a new one which causes this to be kinda pointless. You win some, you lose some). If an update has not been previously downloaded, the plain NCAs for the new content will be downloaded.
• Your console will check the NCA headers to see what Rights IDs are required to play the update. Rights IDs are essentially "handles" to titlekeys -- every rights ID corresponds exactly to one titlekey, globally. Typically, there is one Rights ID per (title ID, master key revision) combination. I'll also observe that that's pointless because titlekeys get transformed by master key-derived data when decrypted *anyway*, so they don't actually need to change the Rights IDs, but whatever.
• Your console will request from the CDN the tickets for those Rights IDs -- first it will try to obtain a common ticket, and then if that fails it will try to obtain a "personalized" ticket from "ecs" (ECommerce Services). Once both the contents are downloaded, and the tickets are downloaded, the update is installed.

Cool, so that's the process. Let's see why this thread is not possible:

First, your console must decide for itself that it's allowed to go online. sun and aqua both require your console's unique client cert to talk to, and use SSL -- you would need to patch the SSL module to interfere with this process. But let's suppose that the author of the thread has done so, with some secret 4.1.0 hax that he has that I don't know about, for the sake of argument.

Your console must then successfully authenticate with the dauth server. This requires it to know secret information stored in sysmodule NSOs in the sysupdate. Thus, for you to do this, you would need to have both patched the SSL sysmodule to disable verification, and patched the system's authentication code to send the correct data and user agents. This would require you to have dumped the code for the latest system update. You'll understand, I hope, if I simply do not believe you have done those things.

If you've done that patching correctly, the rest of the process should go totally smoothly -- you'd run into problems with "ecs", but since all updates use common tickets you don't have to worry about that.

However, your process is not one you're claiming is based on secret 4.1.0 haxx. I do not believe you have developed the relevant system patches, nor that you've dumped the 5.x sysmodule code required to know the secrets you need to authenticate. Hence: this thread's claims are not possible.

SciresM is that really you.

Been waiting all day for you input.

Glad your hear and I appreciate your insight. I'll clarify myt finding really soon. All I asked from the community was to be patient.