Okay so I have seen -put in any big number that comes to your mind here- of threads were Noobs are writing stuff like:
...does this works with arm9loaderhax cfw?...
... does this works with Luma cfw...
So to every Noob. here you have your explanations on what it is and why you are wrong with your questions. If people don´t understand what you mean they can´t answer you. so here we go:
So for short Neither ARM9LOADERHAX is a CFW it is a persistant (low-level) system exploit, nor Luma3DS is a FW Replacement, it is a Signature Patcher.
Hope this clears things up to the Noobs.
Thanks.
Have a good day Everyone.
...does this works with arm9loaderhax cfw?...
... does this works with Luma cfw...
So to every Noob. here you have your explanations on what it is and why you are wrong with your questions. If people don´t understand what you mean they can´t answer you. so here we go:
Custom firmware, also known as aftermarket firmware, is an unofficial new or modified version of firmware created by third parties on devices such as video game consoles and various embedded device types to provide new features or to unlock hidden functionality. In the video game console community, the term is often written as custom firmware or simply CFW, referring to an altered version of the original system software (also known as the official firmware or simply OFW) inside a video game console such as the PlayStation Portable and Nintendo 3DS.
Custom firmware often allow homebrew applications or ROM image backups to run directly within the game console, unlike official firmware, which usually only allow signed or retailed copies of software to run. Because custom firmware is often associated with software piracy, console manufacturers such as Nintendo and Sony have put significant effort into blocking custom firmware and other third party devices and content from their game consoles.
Like its predecessor, the Nintendo DS, the modding scene of the Nintendo 3DS can involve flash cartridges (see Nintendo DS and 3DS storage devices) rather than custom firmware, but custom firmware also exists for the Nintendo 3DS (although it isn't really custom firmware per se) and is compatible with any system version with an ARM9 kernel exploit. However, using a kernel exploit on system versions 11.2 and below, users can gain the ability to run custom firmware. One example is Luma3DS, the current most widely used CFW, which allows unsigned CIA (CTR Importable Archives) files to be installed on the Nintendo 3DS devices, provides region-free features, etc.. CFWs such as RxTools and Pasta have been considered obsolete by now. Other CFWs include Corbenik CFW (with a lot more control than Luma, but not meant for newbies), ReiNAND, on which Luma3DS (previously known as AuReiNAND) is based, Cakes CFW (which is the inspiration for Corbenik) and continue to offer support for EmuNAND/RedNAND, a CFW feature that boots the system from a partition of the SD card containing a copy of the 3DS' NAND memory. These EmuNANDs can protect the 3DS system from bricking, as the usual system NAND is unaffected if the emuNAND is no longer functioning properly or is otherwise unusable. EmuNANDs can also be updated separately from the usual system NAND, making online play and Nintendo eShop access possible on outdated 3DS system versions. However, most people currently use ARM9LoaderHax, a boot-time kernel exploit that allows people to safely use SysNAND and update it, as CFWs make it protected on boot, meaning an update won't remove it.
Custom firmware often allow homebrew applications or ROM image backups to run directly within the game console, unlike official firmware, which usually only allow signed or retailed copies of software to run. Because custom firmware is often associated with software piracy, console manufacturers such as Nintendo and Sony have put significant effort into blocking custom firmware and other third party devices and content from their game consoles.
Like its predecessor, the Nintendo DS, the modding scene of the Nintendo 3DS can involve flash cartridges (see Nintendo DS and 3DS storage devices) rather than custom firmware, but custom firmware also exists for the Nintendo 3DS (although it isn't really custom firmware per se) and is compatible with any system version with an ARM9 kernel exploit. However, using a kernel exploit on system versions 11.2 and below, users can gain the ability to run custom firmware. One example is Luma3DS, the current most widely used CFW, which allows unsigned CIA (CTR Importable Archives) files to be installed on the Nintendo 3DS devices, provides region-free features, etc.. CFWs such as RxTools and Pasta have been considered obsolete by now. Other CFWs include Corbenik CFW (with a lot more control than Luma, but not meant for newbies), ReiNAND, on which Luma3DS (previously known as AuReiNAND) is based, Cakes CFW (which is the inspiration for Corbenik) and continue to offer support for EmuNAND/RedNAND, a CFW feature that boots the system from a partition of the SD card containing a copy of the 3DS' NAND memory. These EmuNANDs can protect the 3DS system from bricking, as the usual system NAND is unaffected if the emuNAND is no longer functioning properly or is otherwise unusable. EmuNANDs can also be updated separately from the usual system NAND, making online play and Nintendo eShop access possible on outdated 3DS system versions. However, most people currently use ARM9LoaderHax, a boot-time kernel exploit that allows people to safely use SysNAND and update it, as CFWs make it protected on boot, meaning an update won't remove it.
So above in the CFW Explanation you have more details about Luma. It is not really wrong but also not really true. Luma3DS is basically just a signature Patcher that Patches the Original Firmware. It is not a Firmware replacement at all.
1. Bootrom reads FIRM0, but due to our payload presence, the signature check will fail.
2. It will read FIRM1 on top of FIRM0, and our payload will still be after it.
3. Check its RSA signature, since it's good it will jump to its arm9loader.
4. The arm9loader will use our crafted key to decrypt the ARM9 binary as garbage, then jump to the kernel entrypoint.
5. With our key the garbage kernel entrypoint will make the cpu jump to our payload location.
6. Code execution!
2. It will read FIRM1 on top of FIRM0, and our payload will still be after it.
3. Check its RSA signature, since it's good it will jump to its arm9loader.
4. The arm9loader will use our crafted key to decrypt the ARM9 binary as garbage, then jump to the kernel entrypoint.
5. With our key the garbage kernel entrypoint will make the cpu jump to our payload location.
6. Code execution!
1. Ensure the firm0 and firm1 partitions are arranged such that the size of firm0 is greater than firm1. Both need well-signed FIRM headers so that bootrom will load them into memory.
2. Put the payload at *(firm0 + (sizeof firm0 - sizeof firm1)).
3. Find a key that, when decrypting the firm1 arm9bin, causes a jump to the payload in the size difference between firm0 and firm1.
4. Encrypt the key and place it at the second key of the secret sector (sector 0x96, offset 0x12c00).
5. Write the firm0 and firm1 to NAND.
6. Boot.
7. Bootrom9 loads up firm0 and find the SHA-256 hash mismatching because of the payload at the end of firm0.
8. Bootrom9 loads up firm1 on top of firm0, decrypts it and jumps to it.
9. arm9loader decrypts the arm9bin with the preinstalled key and jumps to it.
10. The first instruction in the arm9bin jumps to the payload.
2. Put the payload at *(firm0 + (sizeof firm0 - sizeof firm1)).
3. Find a key that, when decrypting the firm1 arm9bin, causes a jump to the payload in the size difference between firm0 and firm1.
4. Encrypt the key and place it at the second key of the secret sector (sector 0x96, offset 0x12c00).
5. Write the firm0 and firm1 to NAND.
6. Boot.
7. Bootrom9 loads up firm0 and find the SHA-256 hash mismatching because of the payload at the end of firm0.
8. Bootrom9 loads up firm1 on top of firm0, decrypts it and jumps to it.
9. arm9loader decrypts the arm9bin with the preinstalled key and jumps to it.
10. The first instruction in the arm9bin jumps to the payload.
So for short Neither ARM9LOADERHAX is a CFW it is a persistant (low-level) system exploit, nor Luma3DS is a FW Replacement, it is a Signature Patcher.
Hope this clears things up to the Noobs.
Thanks.
Have a good day Everyone.
Last edited by adrifcastr,
