TX Announces revolutionary update to SX OS v2.0 with 'EmuNAND' and more

Rune · Sep 24, 2018

D-Jay said:
NAND on a mSD... really, dude? C'mon... just think about it again.

Imagine using an emuNAND to protect your real NAND from a potential brick. Then imagine how dumb it would be to put that emuNAND on the NAND that you're trying to protect...just think about it again.

Deleted User · Sep 24, 2018

monkeyman4412 said:
To further elaborate.
What would look right. (ignoring safe partition, including it with system partition. And simplified since also ingoring boot partitions.)
System partition(4gb)+ User partion=32
system partition-system partitions files+ Usernand - usernand files=available space. So let me do some math here and pretend somethings. Let's say I have used 10gb of my switches user partition. And the system partition takes let's say 4gb and I'm using 2gb of it.
28-10=18gb Usernand availability. 4-1=3gb system availability.
Total nand size
18+10+3+1=32
So now let's have a situation where let's say it is duped (sx os emuannd). And that space is taken off system nand partition. Meaning we have 2gb instead of 4gb.
28-10=18 total User nand available. 2-1= system nand available
available user space+ User taken space + system space + system space taken=total nand
28+2=30 which would not equal 32. Why? because another partition that space neither has access to.

What the F*CK are you talking about?? why are you over complicating things with your own made up counting system?? its not that difficult dude..... Have you ever used a PC before?? go into Disk Management and it has a visual representation of the total disk size and the partitions within the disk etc. The total size will always be the same regardless of the data it does or doesn't have on it or regardless of the partitions size or space etc.

Tilde88 · Sep 24, 2018

Turns out everything I was saying is true, and know-nothing gbatempers just making stuff up in their head, and spreading propaganda.

Sigh...

rrocha · Sep 24, 2018

There's generally a lot of hate towards TX to the point that some things get distorted. Like people saying that there's only stolen code inside their solution. There's enough proof that a big chunk of what makes SXOS is based on uncredited OS projects. But XCI loader is unique, the DNS simulator that powers their stealth mode is not implemented elsewhere and now this emuNAND that's also unique.

Bear in mind that people stating that there are free and/or better alternatives available might be missing the point: their target audience! And not only that, but it feels like we've reached into a point that it does not matter what they put out, people will always complain even if they don't use the product. First, no new original features and all stolen code. Now that a new original feature is announced, is because it's not implemented the way you think it should be implemented. Then it's all about the speculation of it being detectable or not...

SX2.0 does in fact fill in a gap that wasn't possible before in an easy way: to be able to have 6.0.0 without burning fuses, without auto-RCM and its dangers in an easy reversible way while still retaining your lower firmware so you can wait for a better coldboot exploit to come somewhere along the road.

In my specific case, my console never connected to any network whatsoever and shipped with 4.1.0. I do not like auto-RCM let alone the idea of having some glitch that would cause my fuses to blow because I might run a higher FW version by mistake. Now I am able to have v6 and enjoy all the content while we still wait on some new exploits and developments to happen for lower version.

Just because you have alternative methods to do something, you prefer a specific file format or you're comfortable enough to have feature A or feature B on your switch, remember that there are other people that prioritize different stuff.

That being said, it seems that a couple of things might indeed be broken on SXOS 2.0, like the boot on fw3.0 or even their own autoRCM.
They're not perfect, it sucks that they don't credit the ones that deserve it but for 25USD you get something that (for now) packs 2 unique features whether you like them or not, whether you use them or not: XCI loading and emuNAND/partition redirection

Just my 2 cents

porto · Sep 24, 2018

Hi all,

Here SWITCH OFW 3.0.0 with TX OS 2.0 can't Boot custom FW -- > Black screen
With SX OS 1.9 all is ok

210modz · Sep 24, 2018

Rune said:
Imagine using an emuNAND to protect your real NAND from a potential brick. Then imagine how dumb it would be to put that emuNAND on the NAND that you're trying to protect...just think about it again.

It was common practice to split the bios chip on a original xbox and flash 2 or 4 different banks. If one got bricked, you could still boot off a different bank. This is nothing new. Stop making yourself look stupid on the internet.

Ev1l0rd · Sep 24, 2018

210modz said:
It was common practice to split the bios chip on a original xbox and flash 2 or 4 different banks. If one got bricked, you could still boot off a different bank. This is nothing new. Stop making yourself look stupid on the internet.

A common practice isn't necessarily a right practice. A lot of people still used to run Gateway solutions, even when arm9loaderhax became a thing. Doesn't make running Gateway right in any shape or form.

Flying Scotsman · Sep 24, 2018

porto said:
Hi all,

Here SWITCH OFW 3.0.0 with TX OS 2.0 can't Boot custom FW -- > Black screen
With SX OS 1.9 all is ok

2.0 doesn't work on 3.X devices. You'll have to downgrade to 1.9 if you want to use SX. That or update to 6.0, then 2.0 will work.

porto · Sep 24, 2018

zenamez said:
2.0 doesn't work on 3.X devices. You'll have to downgrade to 1.9 if you want to use SX. That or update to 6.0, then 2.0 will work.

Thanks for your help.
I hope this bug is solved in new version 2.1

Todesking · Sep 24, 2018

Glitchk0ud1001 said:
i am on 6.0 and still waiting for definitive way to hack the switch like ntrboothax

So you can't install a cfw on a switch that is on 6.0 and has never installed a cfw before?

scroeffie · Sep 24, 2018

stil no external hdd support

210modz · Sep 24, 2018

Ev1l0rd said:
A common practice isn't necessarily a right practice. A lot of people still used to run Gateway solutions, even when arm9loaderhax became a thing. Doesn't make running Gateway right in any shape or form.

Feel free to explain otherwise.

Deleted User · Sep 24, 2018

rrocha said:
There's generally a lot of hate towards TX to the point that some things get distorted. Like people saying that there's only stolen code inside their solution. There's enough proof that a big chunk of what makes SXOS is based on uncredited OS projects. But XCI loader is unique, the DNS simulator that powers their stealth mode is not implemented elsewhere and now this emuNAND that's also unique.

Bear in mind that people stating that there are free and/or better alternatives available might be missing the point: their target audience! And not only that, but it feels like we've reached into a point that it does not matter what they put out, people will always complain even if they don't use the product. First, no new original features and all stolen code. Now that a new original feature is announced, is because it's not implemented the way you think it should be implemented. Then it's all about the speculation of it being detectable or not...

SX2.0 does in fact fill in a gap that wasn't possible before in an easy way: to be able to have 6.0.0 without burning fuses, without auto-RCM and its dangers in an easy reversible way while still retaining your lower firmware so you can wait for a better coldboot exploit to come somewhere along the road.

In my specific case, my console never connected to any network whatsoever and shipped with 4.1.0. I do not like auto-RCM let alone the idea of having some glitch that would cause my fuses to blow because I might run a higher FW version by mistake. Now I am able to have v6 and enjoy all the content while we still wait on some new exploits and developments to happen for lower version.

Just because you have alternative methods to do something, you prefer a specific file format or you're comfortable enough to have feature A or feature B on your switch, remember that there are other people that prioritize different stuff.

That being said, it seems that a couple of things might indeed be broken on SXOS 2.0, like the boot on fw3.0 or even their own autoRCM.
They're not perfect, it sucks that they don't credit the ones that deserve it but for 25USD you get something that (for now) packs 2 unique features whether you like them or not, whether you use them or not: XCI loading and emuNAND/partition redirection

Just my 2 cents

You seem knowledgeable and unbiased so could you clarify as few of these things for people who dont know? for instance the DNS simulator what makes it unique compared to using the switch wiki DNS address etc?

oleg77 · Sep 24, 2018

rrocha said:
(...)
And not only that, but it feels like we've reached into a point that it does not matter what they put out, people will always complain even if they don't use the product.

People will always complain ESPECIALLY if they don't use the product...

@rrocha : Thanks for your explanation to use it to stay at stock 4.1 OFW and still use latest games with no AutoRCM or burned fuses. I have bought recently an unpatched 4.1 (second) console, so this is good news. I also have to think about the exFAT compatibility issue (if I update to 6.0 in emuNAND and use an exFAT sd card, with stock 4.1 'not exFAT ready' OFW, is there still a problem ?).

rrocha · Sep 24, 2018

aleuts said:
You seem knowledgeable and unbiased so could you clarify as few of these things for people who dont know? for instance the DNS simulator what makes it unique compared to using the switch wiki DNS address etc?

They are executing the same basic principle but instead of a manual config and the need to have a service running somewhere (like the switchbru DNS), it is running on the console itself. To my knowledge and as of today, there's no other homebrew or CFW module that does it like this.

Deleted User · Sep 24, 2018

rrocha said:
They are executing the same basic principle but instead of a manual config and the need to have a service running somewhere (like the switchbru DNS), it is running on the console itself. To my knowledge and as of today, there's no other homebrew or CFW module that does it like this.

So although the features between the two (SX OS and CFW) is the same, it seems like SX OS is more "idiot prof" is that fair to say?

ShadowOne333 · Sep 24, 2018

RY0M43CH1Z3N said:
Because you need your 15GB from switch internal storage...

Small note to avoid confusion:
- The original NAND partition is "shrunk" only in the sense that most of the unused space is discarded when copying it. This means the new copy will be smaller in size (around half of the original one), but the original remains unchanged.
— Mike Heskin (@hexkyz) September 23, 2018

And there's also this post made by @json in this thread:
https://gbatemp.net/threads/how-does-sx-os-emunand-work.518936/

Which imo ends all bullshit once and for all.
All other maggots complaining, please stfu already xD

json said:
Since everbody seems to have an idea how Emunand works by just looking at the release notes, I thought I'd try and find out myself how exactly Emunand in SX OS actually works. No bullshit claims, real facts.

So what I did was create a NAND backup without emunand, and then make another NAND backup after emunand was created.

Here's what I found out so far:

- boot0 is unmodified
- boot1 is modified with EMUNAND0 tacked at the end (some unused area)

- GPT is UNMODIFIED
- All partition locations / sizes are UNMODIFIED
- Everything is unmodified except for the USER partition, in which a few new files have been created (called NAND01.bin, NAND02.bin and so on)

That means NO resizing has taken place. Only new files have been created, like regular Nintendo OS would do.

So from what we can conclude so far: OFW mode is actually perfectly safe. Nintendo would need to actively start detecting the EMUNAND0 magic in boot1 or start to detect the new files, which would be hilarious if they would start to do so. This detectable point is actually moot, because with EmuNAND stored on the microSD, Nintendo would be able to detect it too if they actively start to do so.

The resized partition claims that everyone has been spouting are bullshit.

Ok so now lets take a look from what exactly is in these NAND bin files?

As it turns out, it mimics the layout of the Switch eMMC but inside the NAND files! It's layout it split into multiple NAND bin file parts.

Here's what I found out :
- boot0 in emunand is 100% exactly the same as the real one
- boot1 in emunand is 100% the same as the real one (without the EMUNAND0 magic)
- GPT in emunand is SAME as real one
- All partitions are the SAME except the USER partition.

So far everything is the same, and now here comes the difference: The emunand USER partition volume size is 15GB. SMALLER than the real one.
That's it. That's the only difference.

I think it is possible to have the USER partition claim it is the same size as the real USER partition, but fill up the FAT table with clusters marked as USED.
HEY TX ARE YOU LISTENING? This would make it EXACTLY the same as real USER partition from the Switch's standpoint!

But with that said, I don't see any telemetry sending the USER partition size so it does not really matter for now.
If I am mistaken on this, let me know what telemetry it is sending and I will amend it here.

The "NANDTotalSize" telemetry seems something people claim is changed but I have not checked it yet. I will do so later.

That's it for now what I managed to discover, but I think it is safe to say people are spouting bullshit so far without actual FACTS.

One more note: Since the NAND bin files are located inside the USER partition, this cannot be supported with trivial changes to the FS sysmodule.

For this to work you need to actually .. say.. EMULATE the eMMC read/write commands with patches in the FS sysmodule.

whateverg1012 · Sep 24, 2018

SX OS finally does something "original" and it's likely to cause bans, and in some cases bricks, making it pointless and dangerous. What a waste.

rrocha · Sep 24, 2018

aleuts said:
So although the features between the two (SX OS and CFW) is the same, it seems like SX OS is more "idiot prof" is that fair to say?

I'd put it more like this: aimed for either the less tech savvy or for the ones that don't want to be bothered following multiple github/project pages on the watch for new developments.

chest0r · Sep 24, 2018

can someone tell me how to update fw from 5.1 to 6.0 with choidujournx in sx os with booted in emunand?

I mean does choidujournx Works now in sxos? Readed some old posts where it doesnt

Deleted User · Sep 24, 2018

chest0r said:
can someone tell me how to update fw from 5.1 to 6.0 with choidujournx in sx os with booted in emunand?

I mean does choidujournx Works now in sxos? Readed some old posts where it doesnt

the guy above you @rrocha made a guide

Well-Known Member

Deleted User

Guest

Well-Known Member

Developer

Active Member

Well-Known Member

(⌐◥▶◀◤) girl - noirscape

Well-Known Member

Active Member

New Member

Well-Known Member

Well-Known Member

Deleted User

Guest

Active Member

Developer

Deleted User

Guest

QVID PRO QVO

Well-Known Member

Developer

Active Member

Deleted User

Guest

Similar threads

Popular threads in this forum