Hacking Question Hekate and Atmosphere - exosphere.bin, kip1, kip1patches

[TheZoc]

Hello,

I couldn't find anything about exosphere.bin, so I thought it would be good to ask here:

The last time I updated my sdcard for atmosphere, I used a bunch of sources (mainly sdsetup.com) to end up with my current config, which I really enjoy.
Still, I have a few (ok, a bunch of) questions that I couldn't find answer while searching and I could really appreciate if you guys could help me out here:

This is my current hekate_ipl.ini (short and sweet):

[config]
autoboot=0
autoboot_list=0
bootwait=5
customlogo=1
verification=2
backlight=100
autohosoff=0


{-- Custom Firmwares --}
[CFW]
kip1=modules/required/loader.kip
kip1=modules/required/pm.kip
kip1=modules/required/sm.kip
kip1=modules/required/fs_mitm.kip
secmon=modules/required/exosphere.bin
kip1patch=nogc
kip1patch=nosigchk
atmosphere=1
{ }

So, here are the questions:

1. Where did exosphere.bin come from? While I did find exosphere code, I couldn't find a binary version of it (Maybe custom compiled by sdsetup guys?), where can I find it? (Compiling myself?)
   As far as I understood, that replaces the "security monitor", but it's not distributed by atmosphere; instead it's bundled inside atmosphere binary.
   
   I compiled my own version of exosphere.bin now, based on Atmosphere 0.8.3. Just waiting on info about warmboot to try and use it (question 4a)
   
   
2. What are those kip1 patches, and where did they come from? The best info I could find is that those are memory patches applied on the fly by hekate upon booting, BUT I can't read the data in those files, I couldn't find where they did come from, how they are generated, nor if they're system version dependent or works in every firmware version
   
   When compiling atmosphere, I noticed it generated the same kip files I just asked about, and 2 extra files (boot_100.kip and boot_200.kip). Now I know where they come from, but what are them? This is not a file extension I've seen anywhere else and I'm not sure what they are. Also, I'm not sure what boot_100.kip and boot_200.kip are exactly, even thought I see they're from stratosphere
   
   
3. I understand the kip1patches functionality (at least those two, I think), but same question as before, where did they come from, how they work?
   
   
4. On the hekate documentation, I see a few more options, that I'm having trouble to find what they're for and how to use them. warmboot, kernel and fullsvcperm comes to my mind. These could be asked as:
   • 4a) What is the warm boot binary? (Is this what is loaded after the sleep mode?)
   • 4b) What is full service permission? (What is not allowed if this is disabled?)
   • 4c) How kernel replacement works (Would this completely replace horizon (OS)?)
   
   
5. I have nogc and nosigchk on atmosphere as kip_patches and exefs_patches, respectively. Are those any differences in those? (Like, the are in the memory they're being applied?)
   
   
6. Does applying patches from atmosphere conflicts with patches from hekate in some way? (I assume "atmosphere=1" in hekate config relates to this)

I apologize if for some of you those are basic questions, but most of them are a riddle for me up to now. I decided to stop lurking and abusing the search function (hopelessly ) and ask them here. Hopefully they will help other people too.

Thank you guys in advance for the help!

 

[Goffrier]

boot_100.kip is for 1.0.0 and boot200.kip is for 2.0.0 i think correct me if im wrong

 

[TheZoc]

boot_100.kip is for 1.0.0 and boot200.kip is for 2.0.0 i think correct me if im wrong

This seems correct. While I don't understand why that's needed for those two specific system versions, they only seem to be needed on those cases.
(I didn't dig deep enough to be sure of that, but with a superficial look at the code, that makes sense)

 

[Ratatattat]

Hello,

I couldn't find anything about exosphere.bin, so I thought it would be good to ask here:

The last time I updated my sdcard for atmosphere, I used a bunch of sources (mainly sdsetup.com) to end up with my current config, which I really enjoy.
Still, I have a few (ok, a bunch of) questions that I couldn't find answer while searching and I could really appreciate if you guys could help me out here:

Good questions. Now you know why there is such a band wagon for SXOS. The answers to your questions are probably scattered throughout the forums somewhere but good luck digging it out amoungst the junk and child play. Wish I could be more help but I've retired back to my WiiU when things were done right.

 

[Draxzelex]

Hello,

I couldn't find anything about exosphere.bin, so I thought it would be good to ask here:

The last time I updated my sdcard for atmosphere, I used a bunch of sources (mainly sdsetup.com) to end up with my current config, which I really enjoy.
Still, I have a few (ok, a bunch of) questions that I couldn't find answer while searching and I could really appreciate if you guys could help me out here:

This is my current hekate_ipl.ini (short and sweet):

[config]
autoboot=0
autoboot_list=0
bootwait=5
customlogo=1
verification=2
backlight=100
autohosoff=0


{-- Custom Firmwares --}
[CFW]
kip1=modules/required/loader.kip
kip1=modules/required/pm.kip
kip1=modules/required/sm.kip
kip1=modules/required/fs_mitm.kip
secmon=modules/required/exosphere.bin
kip1patch=nogc
kip1patch=nosigchk
atmosphere=1
{ }

So, here are the questions:

1. Where did exosphere.bin come from? While I did find exosphere code, I couldn't find a binary version of it (Maybe custom compiled by sdsetup guys?), where can I find it? (Compiling myself?)
   As far as I understood, that replaces the "security monitor", but it's not distributed by atmosphere; instead it's bundled inside atmosphere binary.
   
   I compiled my own version of exosphere.bin now, based on Atmosphere 0.8.3. Just waiting on info about warmboot to try and use it (question 4a)
   
   
2. What are those kip1 patches, and where did they come from? The best info I could find is that those are memory patches applied on the fly by hekate upon booting, BUT I can't read the data in those files, I couldn't find where they did come from, how they are generated, nor if they're system version dependent or works in every firmware version
   
   When compiling atmosphere, I noticed it generated the same kip files I just asked about, and 2 extra files (boot_100.kip and boot_200.kip). Now I know where they come from, but what are them? This is not a file extension I've seen anywhere else and I'm not sure what they are. Also, I'm not sure what boot_100.kip and boot_200.kip are exactly, even thought I see they're from stratosphere
   
   
3. I understand the kip1patches functionality (at least those two, I think), but same question as before, where did they come from, how they work?
   
   
4. On the hekate documentation, I see a few more options, that I'm having trouble to find what they're for and how to use them. warmboot, kernel and fullsvcperm comes to my mind. These could be asked as:
   • 4a) What is the warm boot binary? (Is this what is loaded after the sleep mode?)
   • 4b) What is full service permission? (What is not allowed if this is disabled?)
   • 4c) How kernel replacement works (Would this completely replace horizon (OS)?)
   
   
5. I have nogc and nosigchk on atmosphere as kip_patches and exefs_patches, respectively. Are those any differences in those? (Like, the are in the memory they're being applied?)
   
   
6. Does applying patches from atmosphere conflicts with patches from hekate in some way? (I assume "atmosphere=1" in hekate config relates to this)

I apologize if for some of you those are basic questions, but most of them are a riddle for me up to now. I decided to stop lurking and abusing the search function (hopelessly ) and ask them here. Hopefully they will help other people too.

Thank you guys in advance for the help!

Quoting so I don't have to scroll up and down that much.

1. Doing this numerically so I can answer the later questions but I'd just like to point out that Atmosphere is mostly packed into fusee-secondary.bin
2. I'm not even sure where you get those from since those are not included in the official Atmosphere releases but my only guess is what Goffrier already stated
3. Hekate doesn't do a good job of explaining what the kip1patches actually do unfortunately. Nogc, as the name implies, stands for No Game Cartridge (or something similar) and disables the cartridge slot. In case you weren't aware, there is an update for the cartridge slot on firmwares 4.0 and above that once applied renders cartridges not usable on firmwares below 4.0. The purpose of nogc is to prevent this update from being applied by fully disabling the slot. Nosigchk doesn't have to with loading backups you don't own but rather for loading .NCA files not signed by Nintendo. The best example of these are homebrew .NSP files
4. Not a question but needed for proper formatting
   • 4a) Its your warmboot binary. You can replace one but these have to be signed by Nintendo so not much purpose for the end-user
   • 4b) Certain homebrew applications require extended permissions in order to operate such as ChoiDujourNX or Lockpick. While Hekate can do it, nx-hbloader can also do it and is how its commonly utilized now.
   • 4c) The only practical application of this was when people were using LayeredFS to load backups. The way this was done was using a pre-compiled kernal of firmware 5.1 that enabled LayeredFS (LayeredFS hadn't yet been implemented as a sysmodule). Replacing the kernel isn't going to replace the entire OS as its made up much more than just the kernel. Plus, much like the warmboot binary, it needs to be signed by Nintendo
5. Nope, just read differently when booting Atmosphere via Fusee or Hekate
6. I can only assume this question is referring to booting via Fusee (you do not boot Atmosphere, you boot the bootloader which ranges from Fusee, Hekate, ReiNX, SX Loader, etc.). And as explained previously, Fusee and Hekate read files differently. Plus you cannot boot both Fusee and Hekate anyways.

Good questions. Now you know why there is such a band wagon for SXOS. The answers to your questions are probably scattered throughout the forums somewhere but good luck digging it out amoungst the junk and child play. Wish I could be more help but I've retired back to my WiiU when things were done right.

That doesn't mean much when there are plenty of SX OS threads created daily as well as a pinned support thread. You could argue SX OS is even harder to troubleshoot since there is no source code so no one has any idea what they're doing or how to fix it.

 

[urherenow]

along the same lines of this thread, you also get ams_mitm.kip when building it yourself. Is it the same thing as fs_mitm.kip? If not, where does fs_mitm.kip come from? I can't just look at hashes to determine this because unlike many other projects that are strictly built with dkp tools, nothing from a self-built Atmosphere has hashes that match a release (Hekate either, but I read that an updated GCC was being used with that one)...

 

[ZachyCatGames]

along the same lines of this thread, you also get ams_mitm.kip when building it yourself. Is it the same thing as fs_mitm.kip? If not, where does fs_mitm.kip come from? I can't just look at hashes to determine this because unlike many other projects that are strictly built with dkp tools, nothing from a self-built Atmosphere has hashes that match a release (Hekate either, but I read that an updated GCC was being used with that one)...

ams_mitm is a combination of fs_mitm, set_mitm, and bpc_mitm that was introduced in 0.8.4