Homebrew Question HBG shop new update and no full ram access

[blawar]

about incognito bricking :
so basically he can write his homebrew so it doesnt launch if things arent installed like he want them to be, to force user to install the full package or nothing, and with all the shit it does, but he cant write incognito to refuse to be used if not full write access is detected to avoid his own software he made to brick people? (because YES incognito is a program that launch into an environnement, if it use brick the environment, the software is at cause, not the environment; if a disease kill you its the disease fault, not the host one)

...i didn't say anything until know, but wow boi, how amazed i am to see how that guy manage to be an dick every.single.time

damn, if the applet mode change were such a problem for him he could have forket only this, or madea sysmodule, or i dont know what, to have the applet mode act like he want, without touching the title redirection... but nooo...

and "brickers still exist so bis protection doesnt protect against bricking", it protect against the bricks that happened before it was implemented, it protect against erasing those infos... its like saying "nintendo stability update arent update to block hack at all because hack still happen", if it wasnt there there would be even more way to brick people switch... for fck sake...

Title direction was caused by a bug in atmosphere, and was one reason I forked it to fix.

I cant block incognito from running on atmosphere, because there are ways to get it to work on atmosphere (such as the sysmodule or my fork). There is no way to know if it will work without trying to write to the nand, and unfortunately there is a bug in atmosphere where that will sometimes brick the user.

 

[Engezerstorung]

you could make incognito first read and backup an info you know it cannot write if protection is in place, then try to write to this info, if it cannot then you know protection is on, if it can you restore the original info
...or something like that

 

[Lacius]

Title direction was caused by a bug in atmosphere, and was one reason I forked it to fix.

Title redirection wasn't broken by anything other than your fork/malware. Atmosphere didn't break title redirection. Stop making up nonsense.

I cant block incognito from running on atmosphere, because there are ways to get it to work on atmosphere (such as the sysmodule or my fork). There is no way to know if it will work without trying to write to the nand, and unfortunately there is a bug in atmosphere where that will sometimes brick the user.

I can't find any evidence that Incognito bricked an Atmosphere user. You also can't argue that the Atmosphere protections are "pointless and easily bypassable" while simultaneously arguing that Incognito is seriously affected by Atmosphere's protections.

You also can't argue that you can't block Incognito from running on vanilla Atmosphere when you just did the same thing with Tinfoil and it's malware.

 

[blawar]

you could make incognito first read and backup an info you know it cannot write if protection is in place, then try to write to this info, if it cannot then you know protection is on, if it can you restore the original info
...or something like that

There are some major flaws in your approach, however I never said I couldnt make it work. I could bypass atmosphere's cal0 write protection completely and write to the prod info. I'm just not doing extra stuff for an unsupported CFW. Atmosphere users are told atmosphere is unsupported, its frankly a bug atmosphere should fix. i'm not going to write code 3 different times for 3 different CFW's.

--------------------- MERGED ---------------------------

Title redirection wasn't broken by anything other than your fork/malware. Atmosphere didn't break title redirection. Stop making up nonsense.


I can't find any evidence that Incognito bricked an Atmosphere user. You also can't argue that the Atmosphere protections are "pointless and easily bypassable" while simultaneously arguing that Incognito is seriously affected by Atmosphere's protections.

You also can't argue that you can't block Incognito from running on vanilla Atmosphere when you just did the same thing with Tinfoil and it's malware.

Title redirection was broken before I forked it to fix it. Title redirection does not work on vanilla atmosphere when you invert the hotkey to launch hbmenu.

Incognito is open source, putting DRM code in there is pointless and would compromise Tinfoil as it would force me to open source part of Tinfoil. Additionally, installing incognito works with the cal0 disabling sysmodule. The cleanest solution is for atmosphere to fix its brick bug, but atmosphere wont do that because they do not care if users brick using incognito.

 

[Lacius]

I'm just not doing extra stuff for an unsupported CFW.

Doing this with Tinfoil on Atmosphere would solve most problems.

Title redirection was broken before I forked it to fix it. Title redirection does not work on vanilla atmosphere when you invert the hotkey to launch hbmenu.

Using the config settings or using your fork? If it's the latter, you are not describing title redirection being broken on vanilla Atmosphere.

Incognito is open source, putting DRM code in there is pointless and would compromise Tinfoil as it would force me to open source part of Tinfoil. Additionally, installing incognito works with the cal0 disabling sysmodule. The cleanest solution is for atmosphere to fix its brick bug, but atmosphere wont do that because they do not care if users brick using incognito.

1. There is no evidence of a "brick bug" in Atmosphere when using Incognito. I couldn't find it where you told me to look.
2. Putting an Atmosphere block in Incognito would not be pointless if it's actually bricking people on Atmosphere.
3. You don't have to open source part of Tinfoil to add an Atmosphere block to Incognito.
4. There is nothing wrong with open sourcing any part of Tinfoil.
5. If you want the Atmosphere team to care about these alleged Incognito bricks, report it here. Until then, you can't condemn them for not fixing a bug they're unaware of.

 

[blawar]

Doing this with Tinfoil on Atmosphere would solve most problems.


Using the config settings or using your fork? If it's the latter, you are not describing title redirection being broken on vanilla Atmosphere.

1. There is no evidence of a "brick bug" in Atmosphere when using Incognito. I couldn't find it where you told me to look.
2. Putting an Atmosphere block in Incognito would not be pointless if it's actually bricking people on Atmosphere.
3. You don't have to open source part of Tinfoil to add an Atmosphere block to Incognito.
4. There is nothing wrong with open sourcing any part of Tinfoil.
5. If you want the Atmosphere team to care about these alleged Incognito bricks, report it here. Until then, you can't condemn them for not fixing a bug they're unaware of.

You report it and see what they say lol. They will close the issue. Like I said, they dont care if atmosphere users brick while using incognito.

 

[Lacius]

You report it and see what they say lol. They will close the issue. Like I said, they dont care if atmosphere users brick while using incognito.

I can't replicate the issue, so I can't report it, dude.

I'm not going to report an issue I'm skeptical even exists.

 

[hippy dave]

...i didn't say anything until know, but wow boi, how amazed i am to see how that guy manage to be an dick every.single.time

You get used to it I guess.

 

[gizmomelb]

You are correct, your ranting have made me see the error in my ways, i’ll just block all atmosphere next patch problem solved right?

That would be fantastic - then it would cut out a lot of the atmos whining clogging this thread. I feel that letting them use Goldleaf is punishment in itself.

 

[Mopquill]

While my TinfoilMod can remove this requirement for advanced users, the default behavior and configuration of hbl 2.2 is to be considered harmful for homebrew development. It heavily restricts the heap size for Applet homebrew, with no possibility of opt-in or opt-out.

Sorry for late reply, was out of town this weekend. Blawar earlier was saying that you could change the heap size in the ini. If the issue is a petty feud with tinfoil, it's still a valid issue to be filed. I would do it myself if I had more knowledge about Switch development specifically.

I do not believe the current major toolkit developers for the Switch homebrew community have their community's best intentions in mind. While I would appraise them for building a handful of the tooling, it clearly shows that there is no intention to do things properly (libnx: apm bug, HID issue, no support for shared libraries, unstable API, ...) or listen to the developers themselves (see the devkitPro archival case, for an example of this point). Their efforts are commendable, but the results are often poor, disappointing and deceiving.

I understand what you're trying to say, but can you elaborate on this point? Considering the context here, I'm not likely to simply take anyone's word that they are not doing things properly, or that their results are poor, disappointing, and deceiving.

I can only partially agree on your point where you claim that "There's no "standards-compliant with the other two CFWs"". In order for homebrew to be generally as compatible as possible, ReSwitched and Switchbrew had decided on a common ABI for NRO-based homebrew, for which you can find more information about here. However, it has been broken often times; usually for the sake of compatibility. Nowadays, most homebrew will require a firmware modification or custom firmware to work; which defeats the entire purpose of NRO-based homebrew, in my opinion; unless modified. Some of the workarounds for these issues could have been implemented in nx-hbloader itself, but were instead implemented in Atmosphere. "New changes by the front-runner are always going to be out of "standards"" does not mean others should follow or that they should just be accepted. This kind of behavior could mean a lot of trouble in the future.

That looks like documentation, without any sort of idea of who wrote it. I can't conclude based on what you've shown me that there's malice or incompetence on the part of atmosphere/its developers. Like, separate from tinfoil entirely, that would merit filling out an issue saying "this code belongs in nx-hbloader, not atmosphere". Their behavior as outlined by blawar would look like the exact same thing if they're sick of his argument style, and the way he parses logic.

Finally, I can attest that there is no issue with security or privacy with DZ/Tinfoil, as I've reverse-engineered it. Would you wish to confirm this and make further claims about it, feel free to reverse it yourself. I do not believe that closed source software is an issue by itself.

That is unnecessary, he's testified in this very thread. I'm not accusing him of stealing prodinfo or something, I'm saying he refuses to "support" Atmosphere while simultaneously running code that supports it, and blames bricks that happen resultant to his code running as someone else's fault. If a concern is that Atmosphere blocks some writes and not others, leaving things in an inconsistent state and causing a brick, it's trivial to back-up the full section before hand, try writing, then read, comparing what is meant to be written, and if that fails, then you know you're in that situation, and you restore from the backup and fail out. That it ended with a brick, and that those are his philosophies, methodologies, and justifications therein, I can conclude it's unsafe to run, since they're now bundled together and considered a "suite" or whatever. No reverse engineering necessary.

@Lacius I appreciate your posts thus far, said a lot of what I'd say.

 

[blawar]

That is unnecessary, he's testified in this very thread. I'm not accusing him of stealing prodinfo or something, I'm saying he refuses to "support" Atmosphere while simultaneously running code that supports it, and blames bricks that happen resultant to his code running as someone else's fault. If a concern is that Atmosphere blocks some writes and not others, leaving things in an inconsistent state and causing a brick, it's trivial to back-up the full section before hand, try writing, then read, comparing what is meant to be written, and if that fails, then you know you're in that situation, and you restore from the backup and fail out. That it ended with a brick, and that those are his philosophies, methodologies, and justifications therein, I can conclude it's unsafe to run, since they're now bundled together and considered a "suite" or whatever. No reverse engineering necessary.

You are being an armchair programmer, things are not so simple, and your logic is flawed as I stated before. The writes that succeed are random, and when they do occur, it appears to corrupt the prodinfo as in it didnt write what it was supposed to. You also clearly have not read the source code or fully understand it, or you would know that incognito already takes a full backup of prodinfo before attempting to write. Without a reliable way to write to prodinfo, a restore is not possible and the user is bricked until he manually restores nand.

it is easy to sit there and pretend like you know what you are talking about, and that everything I am doing is wrong in your eyes. It is quite another to actually do shit. tldr: bitching is easy, actually doing work is hard.

 

[Deleted-452294]

Sorry for late reply, was out of town this weekend. Blawar earlier was saying that you could change the heap size in the ini. If the issue is a petty feud with tinfoil, it's still a valid issue to be filed. I would do it myself if I had more knowledge about Switch development specifically.

This requires restarting hbloader, among other things. It is not a proper solution, is prone to break on the environment, is CFW-dependent, and would break other homebrews anyway.

I understand what you're trying to say, but can you elaborate on this point? Considering the context here, I'm not likely to simply take anyone's word that they are not doing things properly, or that their results are poor, disappointing, and deceiving.

I believe the examples I've given are sufficient on their own. Many other developers have complained about devkitPro specifically, and same thing for libnx. You can find people complaining about both on GBAtemp.

That looks like documentation, without any sort of idea of who wrote it. I can't conclude based on what you've shown me that there's malice or incompetence on the part of atmosphere/its developers. Like, separate from tinfoil entirely, that would merit filling out an issue saying "this code belongs in nx-hbloader, not atmosphere". Their behavior as outlined by blawar would look like the exact same thing if they're sick of his argument style, and the way he parses logic.

It would, but good luck getting that to work. While it is often claimed that they are open to suggestions, corrections and other fixes, it is hardly the case in practice. See what happened with the recent HID breakage, for example. They, for example, absolutely refuse to make libnx a shared library, or to support shared libraries at all.
Additionally, see here: https://switchbrew.org/w/index.php?title=Homebrew_ABI&action=history
Those people and contributors are people behind the toolchains and libraries. Some of them are ReSwitched, all of them are libnx contributors, and they all are responsible for how the Homebrew ABI is implemented, as they wrote the implementations themselves.

That is unnecessary, he's testified in this very thread. I'm not accusing him of stealing prodinfo or something, I'm saying he refuses to "support" Atmosphere while simultaneously running code that supports it, and blames bricks that happen resultant to his code running as someone else's fault. If a concern is that Atmosphere blocks some writes and not others, leaving things in an inconsistent state and causing a brick, it's trivial to back-up the full section before hand, try writing, then read, comparing what is meant to be written, and if that fails, then you know you're in that situation, and you restore from the backup and fail out. That it ended with a brick, and that those are his philosophies, methodologies, and justifications therein, I can conclude it's unsafe to run, since they're now bundled together and considered a "suite" or whatever. No reverse engineering necessary.

I do not believe it is any developer's job on the Switch Homebrew community to be complying to all of the CFW-specific oddities. It was a conscious decision by Atmosphere's developers to break the normal behavior of the Switch's operating system. Homebrew developers should not be responsible of bricks that happen because of a CFW; or any other kind of behavior that modifies the original firmware's proper functionality.

 

[blackmeds]

so guys.. can i downgrade tinfoil from 4.0 to a 3.9 and magically launch checkpoint using the R button and put cheats?

 

[LightBeam]

Homebrew developers should not be responsible of bricks that happen because of a CFW; or any other kind of behavior that modifies the original firmware's proper functionality.

So basically, Incognito cannot write because Atmosphere is blocking something that the Switch itself wouldn't block (I mean, I have no knowledge in this field but I guess Nintendo wouldn't let people modify their certs so I don't see them leaving this wide open so I'm asking) ? Just like the other CFWs ? Or did Atmosphere start blocking from an update? Involving the fact that it actually changed its behavior after an update

 

[Rahkeesh]

So basically, Incognito cannot write because Atmosphere is blocking something that the Switch itself wouldn't block (I mean, I have no knowledge in this field but I guess Nintendo wouldn't let people modify their certs so I don't see them leaving this wide open so I'm asking) ? Just like the other CFWs ? Or did Atmosphere start blocking from an update? Involving the fact that it actually changed its behavior after an update

There's no software that will modify prodinfo on OFW though. Even if apps weren't sandboxed out of it, Nintendo would surely reject any app that did. That's why its "safe" for atmosphere to block writes to it because nothing official will ever do so.

 

[Mopquill]

You are being an armchair programmer, things are not so simple, and your logic is flawed as I stated before. The writes that succeed are random, and when they do occur, it appears to corrupt the prodinfo as in it didnt write what it was supposed to. You also clearly have not read the source code or fully understand it, or you would know that incognito already takes a full backup of prodinfo before attempting to write. Without a reliable way to write to prodinfo, a restore is not possible and the user is bricked until he manually restores nand.

it is easy to sit there and pretend like you know what you are talking about, and that everything I am doing is wrong in your eyes. It is quite another to actually do shit. tldr: bitching is easy, actually doing work is hard.

You can state it all you like, but fortunately with logic, it's your job to prove any flaws, or I don't have to accept it. I didn't read the source code, I'm operating from what you're saying here. I don't have to sift through your entire source for an unrelated app to discuss your changes to this one.

I think if I didn't know what I was talking about, you wouldn't be paying quite so much attention to me. That said, I'm all for work. I'd actually be more than happy to help develop tinfoil in a direction that doesn't require hijacking a user's hbloader or altering their CFW, but considering the existence of tinfoilmod, your post about blocking atmosphere, and your general tone toward me in general, I suspect your acceptance of my help is unlikely.

This requires restarting hbloader, among other things. It is not a proper solution, is prone to break on the environment, is CFW-dependent, and would break other homebrews anyway.

He's already replacing files on the SD for the entire CFW + Hbloader, does that not require restarting? And how is blocking access to title mode or changing the buttons not breaking things? There's a bizarre double-standard here.

I believe the examples I've given are sufficient on their own. Many other developers have complained about devkitPro specifically, and same thing for libnx. You can find people complaining about both on GBAtemp.

Well, I asked for elaboration in order to understand your opinion. If you don't wish to provide further information, this point of discussion ends here.

It would, but good luck getting that to work. While it is often claimed that they are open to suggestions, corrections and other fixes, it is hardly the case in practice. See what happened with the recent HID breakage, for example. They, for example, absolutely refuse to make libnx a shared library, or to support shared libraries at all.
Additionally, see here: https://switchbrew.org/w/index.php?title=Homebrew_ABI&action=history
Those people and contributors are people behind the toolchains and libraries. Some of them are ReSwitched, all of them are libnx contributors, and they all are responsible for how the Homebrew ABI is implemented, as they wrote the implementations themselves.

I really don't know a lot of the politics behind this, but that doesn't mean I agree with hijacking a user's CFW/normal functioning. Why do you maintain tinfoilmod if you don't also hold this opinion to some degree?

I do not believe it is any developer's job on the Switch Homebrew community to be complying to all of the CFW-specific oddities. It was a conscious decision by Atmosphere's developers to break the normal behavior of the Switch's operating system. Homebrew developers should not be responsible of bricks that happen because of a CFW; or any other kind of behavior that modifies the original firmware's proper functionality.

Software that can brick my Switch if it's on a certain OS should not be bundled with other software that provides an entirely different function. I do understand how if there is a given standard for how an .nro should function, and they're violating that standard, that an app could function in an unknown way, and that could shift the blame to the CFW's team instead, however, with something as serious as a brick, I'd personally go out of my way to either ensure I supported everything, or to ensure it wouldn't run if it didn't. I'd add a CFW whitelist for safety, to ensure there wasn't a brick, as blawar insists has happened. Even knowing an NRO should function a certain way, if I also know that there are more practical restrictions than that, I'm going to avoid doing anything that might cause catastrophic harm. That said, I also think this point of issue is neither here nor there, as incognito is not part of tinfoil, and this is ultimately a gish gallop.

so guys.. can i downgrade tinfoil from 4.0 to a 3.9 and magically launch checkpoint using the R button and put cheats?

Yeah, that should work, or grab tinfoilmod and configure it.

So basically, Incognito cannot write because Atmosphere is blocking something that the Switch itself wouldn't block (I mean, I have no knowledge in this field but I guess Nintendo wouldn't let people modify their certs so I don't see them leaving this wide open so I'm asking) ? Just like the other CFWs ? Or did Atmosphere start blocking from an update? Involving the fact that it actually changed its behavior after an update

So first off, don't get confused, this thread should be discussing tinfoil, not incognito. But it would seem the behavior did change after an update, and incognito is now being bundled with tinfoil, which could cause this issue if someone runs it with latest atmosphere instead of blawar's atmosphere fork. Which is an arguable reason to use the fork for atmosphere specifically, but many of us are taking issue that these changes are being forced to update tinfoil.

 

[frankadank]

@blawar since everyone already knows that HBG's tinfoil can be fully functional on atmosphere without any of the atmosphere mods or mercury; how about you stop this silliness and give the community what they want: a clean functional HBG without mecury and without atmosphere modifications? There's a mod for hbg that does this and several community versions we all know it can be done, its not at all a secret.

That's all you have to do to garner good will from this community you are so desperately trying to explain your point of view and reasons for your odd choices.

 

[LightBeam]

I also don't understand the message preventing to use Tinfoil if we don't use the fork. Why does it have to say that the installation is corrupted ? Just say that Tinfoil is not going to run on vanilla Atmosphere and that it requires your modifications, why would you talk about "corruption" ? It really seems like you're trying to mislead, I hope it's just an impression tho.

 

[blawar]

@blawar since everyone already knows that HBG's tinfoil can be fully functional on atmosphere without any of the atmosphere mods or mercury; how about you stop this silliness and give the community what they want: a clean functional HBG without mecury and without atmosphere modifications? There's a mod for hbg that does this and several community versions we all know it can be done, its not at all a secret.

That's all you have to do to garner good will from this community you are so desperately trying to explain your point of view and reasons for your odd choices.

Never going to happen. run reinx or sx os

 

[frankadank]

run reinx or sx os

Sure I'd be happy to, how about an alternative to mercury?

 

[blawar]

Sure I'd be happy to, how about an alternative to mercury?

reinx and sx os do not have any drm, you don’t need mercury for them.