search

Atmosphere-NX / Atmosphere

Atmosphère is a work-in-progress customized firmware for the Nintendo Switch.
GNU General Public License v2.0
15.04k stars 1.25k forks source link

DevMenu v6.0.1 doesn't work since v0.11.1 #898

Closed OperationNT414C closed 4 years ago

OperationNT414C commented 4 years ago

Bug Report

I am aware that this bug report is a little bit borderline because it refers content that is not possible to legally obtain (without, at least, breaking Nintendo developer NDA). However, as I use this software for its save data management (like EdiZon or Checkpoint would do), I do not think it can be considered as "software explicitly distributed for piracy". You can close the issue, as you mention in bug report condition, if you think it's not the case.

What's the issue you encountered?

I have DevMenu (v6.0.1) installed as NSP. It works fine on Atmosphere v0.10.5. When I switch to v0.11.1, it doesn't work any more: it triggers a "return to HOME" panel on start-up.

How can the issue be reproduced?

Install an unofficial DevMenu NSP (as it's illegal content, I cannot provide any link) which internally contains the v6.0.1 of this debug application Check that it works on Atmosphere v0.10.5 Start it on Atmosphere v0.11.1: it crashes

Crash Report

When the application is started and after the return to HOME, it generates a file in the "erpt_reports" folder: DevMenu_erpt_report.zip

System Firmware Version

Nintendo retail firmware v9.2.0

Environment?

fusee-primary.bin with Atmosphere 0.11.1

Additional context?

Additional loaded modules (I didn't try to disable them to check their influence): sys-ftpd-light v1.0.2 sys-con v0.5.3 emuiibo v0.4

TuxSH commented 4 years ago

We don't support that

Masamune3210 commented 4 years ago

Unfortunately since DevMenu is part of the SDK, it's almost as bad as piracy as it's still N's intellectual property

OperationNT414C commented 4 years ago

Yes, I knew that there was a high risk of refuse when I submitted this issue. I just have to "hope" that this regression will trigger on a more legal scenario.

By the way, if an homebrew triggers the same kind of issue when it is installed as NSP, would it be accepted or the simple fact that this other scenario involves "signature patches" (for unsigned NSP run) is considered as "piracy"?

fincs commented 4 years ago

if an homebrew triggers the same kind of issue when it is installed as NSP

Homebrew isn't "installed" as NSP. Homebrew is exclusively run under nx-hbloader processes, as it is determined by the standard homebrew ABI. "Installed" homebrew has never been a supported way to run custom code.

substanc3-dev commented 4 years ago

As far as I can tell, homebrew when installed as a separate application, bundles and runs nx-hbloader too (directly, instead of overriding existing binaries in an existing app). So the result should afaik be the same. Is there any other reason why this is not supported?

fincs commented 4 years ago

Needs signature checks patched out (i.e. warez), triggers telemetry that makes Nintendo ban the user on sight, and has absolutely zero benefit over just using hbloader. This use case is not supported.

substanc3-dev commented 4 years ago

I might be wrong on this, because I don't really know much about this part of it, but afaik, the signature patches required for this (fs), and patches used for warez (eticket) are different, but that's fair I guess. In terms of telemetry, that's true, this was an issue in the 3DS realm too, but clearly some people are not deterred by it, and find the benefit of convenience worth it.

I mean, it's 100% fair and within your rights to not support this use case, I just struggle to find an actual technical reason why this would be any different from a regular support case. (EDIT: not talking about this specific support request, as this is clearly a non-support (warez) scenario)

fincs commented 4 years ago

No they are not. The only supported way to load homebrew is exclusively through nx-hbloader.