Hacking Lost Super Stable 3d

[The Real Jdbye]

I've been using Samsung Galaxy S mobile phone family since my first smartphone. I also own a PSV. Neither of the screens has signs of burn-in.

For that to happen you have to leave a static screen for days. Normal usage won't damage the screen at all.

Back when Android had a light statusbar (pre-3.0) it was an issue because the statusbar was always there, always in the same position as long as the screen was turned on. This is most likely why they've changed it to a dark one since then. I haven't noticed any burn-in on my 2 year old Note 3 either and I will agree it probably isn't an issue under most normal usage, but in specific cases (that are still very much normal usage) like the one I just mentioned, it can be.

Edit: For the record, I have a friend who got burn-in as a result of the light statusbar on early Android versions so I know it happens.

 

[sneef]

I'm digging that topic... It seems nobody as of today found a fix for the SS3D bug, but the SALT team ?

is there a reason you decided to perform arcane rites of necromancy on this thread, which breathed its last back in May of 2015? I'm not complaining, not at all.. actually, i'm glad you did, because this topic has been on my mind from the first day the bug became apparent. i'm just curious, thats all.

p.s. in fact, the very day i got emunand working, and noticed the crazy bug, I "discovered" the fix within minutes.. mainly because it was clear to me that there was an initialization issue, and because the effect varies in its intensity from boot to boot, i realized the code was not allowing for a proper graceful shutdown, and emunand was booting up expecting the system to be starting from a clean slate. so i figured sleep mode ought to allow things to get back in sync.. and voila! so, a few hours later, or maybe many hours, I posted the fix on gbatemp, excited to make my first significant contribution after 9 years of being a 'temper... and... found out... I'd been ninja'd. oh well...

 

[CreativeMan]

is there a reason you decided to perform arcane rites of necromancy on this thread, which breathed its last back in May of 2015? -snip-

Hi sneef, yes I decided to resurect this thread because I remember how some devs said the actual fix (closing lid, reopening it) isn't "clean", and there was a software way (some kind of reboot patch I guess ?) to do it like it should be done. I waited for Gateway to fix it, then "homebrews" CFW came and I waited again to see if anyone will be able to fix it... Now 8 months later, still nobody except SALT team figured how to fix it. The thing I remember the most is WulfyStylez stating the fix was easy, and now we have his explanation.

This is something fixed by writing good code that assumes nothing about the state of the system at payload runtime. We completely sanitize the state of the GPU and screen by always de-initializing the screen, resetting the GPU, and re-initializing the screen, framebufs, etc. On exit, you also properly need to properly take the screen down in the same way GSP would.
The best payload code for running on bare metal must make absolutely no assumptions about system configuration.

Thanks for your reply WulfyStylez, now it is easier to see where the work has to be done.

 

[Apache Thunder]

Yeah it's unfortunate the 3D bug still hasn't been fixed. My plan to get around the issue when I get my n3DS is to just use Arm9LoaderHax CFW. That stuff runs from hard boot very early in the boot process, so the screen init and low level stuff have to be setup correctly from the get go anyways. All current CFWs (that are public) have to do a soft reboot to do firmlaunch. But with Arm9LoaderHax stuff, the payload occurs before the screen init stuff starts so there's no previous state to worry about assuming it's being started from power off.

Granted, what I'll be using for this isn't going to be as refined as the private CFW team SALT is using. But regardless I'll be satisfied with not having to use emunand as my primary environment. I have some independent stuff I actually still use from time to time that is on my sysnand. So after I migrate over to n3DS, my sysnand stuff will be moved to emunand while my emunand stuff will be moved to sysnand. It will be a very different experience having 10.5 boot up already patched and ready to go. Menuhax was just a crappy stopgap to the true CFW this will give me.

 

[Pikasack]

I've been using Samsung Galaxy S mobile phone family since my first smartphone. I also own a PSV. Neither of the screens has signs of burn-in.

For that to happen you have to leave a static screen for days. Normal usage won't damage the screen at all.

I'm using a Samsung Galaxy S3 hand me down.
And my dad used an app called DigiHUD, now i have stupid numbers burned into the screen...

 

[CreativeMan]

Yeah it's unfortunate the 3D bug still hasn't been fixed. - snip-
Menuhax was just a crappy stopgap to the true CFW this will give me.

Hi Apache Thunder, Arm9LoaderHax isn't public yet or at least not exploited as of today ?

 

[Apache Thunder]

It is. Have you not come across this yet?

https://github.com/delebile/arm9loaderhax/

You'll need a nand mod and a OTP dump for your n3DS to use it. Arm9LoaderHax is needed to dump the OTP hash on current firmwares, so the only viable option for most is to downgrade n3DS to 1.0 to dump OTP.

You CAN NOT use an OTP dump from a different console. You must use an OTP dump from the console you are going to use this on! Also, you'll need to change how CTR_NAND partition is encrypted and copy over the first 200 bytes from an o3DS nand replacing the first 200 bytes on n3DS nand before 1.0/2.0 FW will boot on a n3DS. Good luck with that.

This CFW isn't as user friendly as the previous ones. But it's certainly worth the effort.

 

[amoulton]

The "frying" rumor is a bunch of bull. The majority of power a LCD panel uses is with the backlight. So what extra power it would send for the parallax barrier (which is basically another LCD layer) would not be enough to really damage anything. The 3D bug is probably something with the framebuffers or the parrallax barrier not being enabled correctly.

My (extremely fringe) theory is that Nintendo intends to allow full resolution (800px) in a future N3DS firmware, so that it can stream games from the NX without jaggies.

 

[Apache Thunder]

My (extremely fringe) theory is that Nintendo intends to allow full resolution (800px) in a future N3DS firmware, so that it can stream games from the NX without jaggies.

That isn't going to happen. Because 800x240 would have a very bad aspect ratio and the hardware isn't designed to "span" a single scene across the two frame buffers in this way. Perhaps the GPU can be convinced to do this but since it will never be physically possible to display a game in this resolution (in 2D mode) correctly on the 3DS screen, there's little possiblity of them doing some kind of streaming of games. The 3DS and perhaps even the n3DS doesn't have the power/speeds needed to "stream" a video game while it's playing. (assuming you were wanting to stream FROM the 3DS to the NX.

However you CAN NOT stream games from NX to the 3DS in 800x240 resolution in 2D mode. The screen can not physically present the image correctly in that resolution in 2D mode. If there is any streaming in that resolution, it will be for 3D mode. Not 2D mode, which means what ever image you see with each eye will still be 400x240. No way of increasing that.

 

[amoulton]

That isn't going to happen. Because 800x240 would have a very bad aspect ratio and the hardware isn't designed to "span" a single scene across the two frame buffers in this way. Perhaps the GPU can be convinced to do this but since it will never be physically possible to display a game in this resolution (in 2D mode) correctly on the 3DS screen, there's little possiblity of them doing some kind of streaming of games. The 3DS and perhaps even the n3DS doesn't have the power/speeds needed to "stream" a video game while it's playing. (assuming you were wanting to stream FROM the 3DS to the NX.

However you CAN NOT stream games from NX to the 3DS in 800x240 resolution in 2D mode. The screen can not physically present the image correctly in that resolution in 2D mode. If there is any streaming in that resolution, it will be for 3D mode. Not 2D mode, which means what ever image you see with each eye will still be 400x240. No way of increasing that.

I'm talking about streaming games from the NX to the N3DS. You don't think it would be possible for the NX to render two 400x240 images that display interlaced on the 3DS screen? I'm not an expert, when you get this emunand 'glitch' isn't the screen physically showing you 800 pixels?

 

[Apache Thunder]

The LCD hardware is not setup to enable that resolution when the parallax barrier is disabled. (except in the case where there is a malfunction when booting CFW perhaps). Nintendo won't attempt to make use of this anyways.

 

[amoulton]

The LCD hardware is not setup to enable that resolution when the parallax barrier is disabled. (except in the case where there is a malfunction when booting CFW perhaps). Nintendo won't attempt to make use of this anyways.

My real fevered dream here is that the N3DS is part and parcel to the NX ecosystem, potentially replacing the gamepad.

 

[Thesolcity]

You'll need a nand mod and a OTP dump for your n3DS to use it. Arm9LoaderHax is needed to dump the OTP hash on current firmwares, so the only viable option for most is to downgrade n3DS to 1.0 to dump OTP.

Really? I was just reading the Github page and it was sounding like there was another way.

or exploit the New3DS-only vulnerability (This will just give you the hash of it, so you'll need to change the python script).

Ah well, to hardmod land i go...

 

[Apache Thunder]

Yeah. But you need to brute force a key to use Arm9LoaderHax to get a payload that dumps OTP hash. This would defeat the point of getting OTP because at that point you already have code execution.

Hence right now, downgrading 1.0/2.0 remains the fastest way to dump OTP.

 

[CreativeMan]

It is. Have you not come across this yet?

https://github.com/delebile/arm9loaderhax/

You'll need a nand mod and a OTP dump for your n3DS to use it. Arm9LoaderHax is needed to dump the OTP hash on current firmwares, so the only viable option for most is to downgrade n3DS to 1.0 to dump OTP.

You CAN NOT use an OTP dump from a different console. You must use an OTP dump from the console you are going to use this on! Also, you'll need to change how CTR_NAND partition is encrypted and copy over the first 200 bytes from an o3DS nand replacing the first 200 bytes on n3DS nand before 1.0/2.0 FW will boot on a n3DS. Good luck with that.

This CFW isn't as user friendly as the previous ones. But it's certainly worth the effort.

Absolutely not ! I don't know how I could miss that... I thought the downgrade method and OTP dumping was only a way to get missing keys and then unscramble them to use them. Thanks for the tip Apache Thunder, I'll look into this
NAND mod is required because we can't have OTP aera access from software dumps or just in case of brick ?

 

[Apache Thunder]

NAND mod is technically not needed. But there's a very high brick risk when doing this if something goes wrong. (that and updating from 1.0 after dumping OTP may also cause a brick). So yeah. NAND mod needed.

 

[EmuAGR]

Back when Android had a light statusbar (pre-3.0) it was an issue because the statusbar was always there, always in the same position as long as the screen was turned on. This is most likely why they've changed it to a dark one since then. I haven't noticed any burn-in on my 2 year old Note 3 either and I will agree it probably isn't an issue under most normal usage, but in specific cases (that are still very much normal usage) like the one I just mentioned, it can be.

Edit: For the record, I have a friend who got burn-in as a result of the light statusbar on early Android versions so I know it happens.

I'm using a Samsung Galaxy S3 hand me down.
And my dad used an app called DigiHUD, now i have stupid numbers burned into the screen...

Those cases are "days with a static image" scenarios. I should've said "high contrast static image". Black images also creates burn-in, since back pixels are less used and appear brighter. I've been playing Love Live School Idol Festival for hours for two years and there's no burn-in in my phone.

 

[SirByte]

NAND mod is technically not needed. But there's a very high brick risk when doing this if something goes wrong. (that and updating from 1.0 after dumping OTP may also cause a brick). So yeah. NAND mod needed.

With GPUs getting more processing power every 6-12 months, when will we arrive at a point that bruteforcing a working key will become realistic (say within a week or two of searching)? Not everyone *cough*me*cough* is very handy soldering very tiny wires. Plus a software-only solution (not necessarily all running on the 3DS) always beats a hardware-required solution.

Question though: why would updating from 1.0 cause a brick if you're updating by official means? The some time ago there was someone who got a 1.0.0 3DS asking what they could do to help, wouldn't that 3DS face the same problems?

 

[Apache Thunder]

Because n3DS wasn't meant to run 1.0. So updating it may not work properly.

 

[CreativeMan]

Because n3DS wasn't meant to run 1.0. So updating it may not work properly.

Yeah, better safe than sorry... SysUpdater isn't the most reliable solution, even SafeSysUpdater isn't that safe. Isn't a software NAND restoration process safer to get back to 9.2 ?