Sigh... I didn't really want to write a whole blog post about this, but since people keep paraphrasing me out of context (or just plain wrongly) I figured it might be beneficial for those few who care.
So, the SX OS brick code... I'm going to try and explain all this again one last time in a good old Q&A style (Qs have been exaggerated for comedic purposes).
Q: lul u bricked! that's what you get for tryin to crack the almighty SX OS!
A: Yes I know this isn't really a question. Apparently people think I'm butthurt about this or that I simply have no clue how this happened.
Sorry to disappoint you, but I wouldn't try to run a closed-source piece of software at a system's highest possible level of execution privilege if I wasn't sure of what could happen. Naturally, I reserved one unit that I didn't care much about for experimenting with this.
Sure, it sucks to go through the process of restoring it, but I was willing to do it and no I'm not sad/mad/annoyed/butthurt/whatever about what happened. I guess people inferred a tone from my original first tweet (was it the emoticons?), but the purpose of the PSA was merely informative.
Q: You SJWs try anything to discredit TX! First it was "itz goin to get cracked day 1" now it's "oh no! brick code! stay away!".
A: Another non-question. For starters, I'm not the author of the first claim, I never underestimated the preventing measures in place for their software.
As for the second claim, I couldn't care less about what you do with your system. I'm not here to tell you to stay away from their product because it has code that can brick your NAND, I was just doing an informative tweet. Something I've done in the past regarding the Switch itself.
Q: TX has a solid 15 year reputation! How can you find yourself superior to them?
A: Even though I never claimed to be above them, I've been around security for almost 18 years now. What exactly does that prove anyway?
Q: Why are you wasting time REing SX OS instead of working for the free open-source alternatives you defend so much?
A: I'm still doing active work on Atmosphère (writing critical parts of fusee from scratch), just because you're not seeing commits it doesn't mean work isn't getting done.
As for REing the OS, why not? It's a challenge. I'm not trying to break their product to make them lose money or whatever crappy excuses I've seen people throwing around. If I worked on cracking the Switch itself, why shouldn't I try to do the same with their product? It's out there for anyone to grab and has multiple layers of obfuscation, seems like an interesting puzzle to me.
Q: Yeah right, you ReSwitched folks are all the same!
A: To be accurate, I'm not part of ReSwitched. I work independently while collaborating with multiple parties such as ReSwitched and Switchbrew.
This doesn't mean I don't share their views, because I do agree with several people on multiple things, but I speak for myself whenever I deem fit.
Q: Oh, but you attacked TX in the past!
A: I did yes. I have no problems admitting that in my opinion what they do is despicable, but that's a personal and subjective view. I'm also intelligent enough to not mix this with objective work such as reversing their products.
Q: Pffft. Can you even prove they have brick code?
A: Run this script on the folder where you have the "boot.dat" file: https://gist.github.com/hexkyz/238fe509911f5b3e2aa286295e235e27
It will generate a few files, but we're only interested in the "data_80000000.bin" one. This is a payload that runs in RAM and is composed of various chunks of code that decrypt and re-encrypt themselves to prevent people from live debugging their code.
Afterwards, run this other script in the same folder: https://gist.github.com/hexkyz/d5b3f5b1700b507b41e7fc1dc12e8dfd
You will get a file called "data_80000000_unpacked.bin". This is the payload with its chunks decrypted and placed in the proper memory addresses. Open this in IDA or any other disassembler of your preference (the binary is AARCH64, little endian and base offset is what's in the file name: 0x80000000) and locate sub_80306200.
What you're seeing there is performance monitor (using the Cortex-A57 CP15 registers c9, c12 and c13) that watches over the overall execution time of this payload. If the timing doesn't match what the payload expects, a different code path is taken (and different chunks of code will be decrypted and executed). You'll have to dig a bit, but eventually the MMIO register 0x700B0600 (comes from 0x8000407C after deobfuscation), which is the Tegra's SDMMC4 (eMMC) base address, will be accessed to perform the aforementioned issuing of the MMC_LOCK_UNLOCK command (CMD42).
The password used is generated in the same fashion as Gateway's brick code for the 3DS. In my case, since I was messing with the code, it picked up the password seed from random garbage in the stack so it would've been very difficult (if not impossible) to regenerate it.
In theory, it should be really difficult for this mechanism to trigger at random, but it is possible. The performance monitor features of the CPU are prone to mistakes just like anything else.
Q: What's your endgame with this then?
A: Nothing, I just like to crack DRMs.
So, that's it I guess.
I'm a strong advocate of the idea that if a product is good enough (regardless of their origins or purposes) it should be able to stand by itself. Seeing a good amount of people actively defending the SX OS and getting pissed by just about anything is making me believe that TX themselves don't trust this product.
I actually know Team Xecuter's history and I've even had some of their products in my hands a long time ago. What I'm learning by reversing the SX OS doesn't resonate at all with the TX that worked on solutions for the Xbox family. It's not the first time TX releases software to accompany their hacks, but I don't remember them including brick code in their products.
In sum, my stance on piracy is very clear: it's a despicable and toxic practice that goes directly against the morals and values of the homebrew community. It completely discredits our attempts to show companies that we are capable of building positive solutions by modifying their products.
That being said, I don't mix my personal views with my attempts to reverse engineer this product and I certainly wouldn't tweet about it if I wasn't sure of what I found.
Anyway, my guinea Switch is being restored at the moment and this didn't hinder in the slightest my progress in cracking the SX OS. Ironically, it had the reverse effect since I was able to observe where and how the next stages are loaded into which in turn allows to improve emulation solutions to further crack the code.