B9sTool 3DS

From GameBrew
b9sTool
B9stool3ds.png
General
Authorzoogie
TypeExploits
Versionv7.0.0
LicenseMIT License
Last Updated2023/02/24
Links
Download
Website
Source

B9sTool is a tool that utilizes the "FIRM partitions known-plaintext" exploit to enable DSi mode firm writing on the 3DS. It achieves this by using a 'boot.nds' file.

General Info

  • This app only writes to FIRM0, not FIRM1, so it should be safe given your FIRM1 is not corrupt or a9lh'd.
  • Never use this if sighax/b9s/arm9loaderhax is already installed (on any firmware)! There are measures in place to try to prevent anything bad from happening if this is done, but it is still not intended.

Compiling:

  • Simply clone, checkout the submodule, supply a boot9.bin and the latest boot9strap.firm in the embedded_files directory, then compile with make. Needs the latest libfat version.

Firmware info:

  • 7.0.0 and above work on any firmware from 3.0 and above.
  • Previous versions of b9stool only worked on certain firmware versions, don't use those without a very good reason.

Instructions

Use https://3ds.hacks.guide/.

WARNING: Never, under any circumstance, use this homebrew in conjunction with a youtube/video guide of any kind!

Changelog

7.0.0 Special Thanks to @aspargas2 for these changes:

  • A safety feature that searches everywhere I could think of on the SD and locations in NAND for the system's OTP, and if it finds it it'll use software AES to encrypt the target firm and write it to firm0 regardless of what was in there to begin with. I have dubbed this "safe mode".
  • If the OTP is not found, then instead of doing the traditional XOR attack, it will modify the system's NAND header to create 5 firm partitions, each only 0x200 bytes big, and all within the region of NAND that firm0 would usually occupy. (It leaves firm1 untouched in doing this, so technically the system has 6 firm partitions in this state). It then does the known-plaintext attack 5 times, trying to write a minimal, 0x200-byte firm payload to each of the firm partitions. This lets it get 5 guesses at the current contents of firm0. But because only a 0x200 byte subsection of the firm needs to match with our guess, we can actually support very large ranges of firms at once. Specifically, the attached build should be able to use the XOR attack to install b9s over any native firm 3.0 or newer, any release boot9strap version, any release Fastboot3DS version other than 1.0, and any release Luma3DS version up to 11.0. Really, only native firm should need to be in this list because any system that has already been touched by sighax will hopefully have an OTP dumped somewhere and trigger the safe install. XOR support for other firms is just a "because I could" thing that will hopefully never be used.
  • In both of these cases, a custom build of safeb9sinstaller is chainloaded to cleanly install boot9strap to both firm partitions, not just firm0.
  • The old special handling for a9lh systems has been removed entirely; it is now handled fine in regular XOR mode.
  • b9stool now builds with -Wall -Wextra -Wpedantic -Werror, and I have done some tweaking to the build_headers.py script to hopefully make it less frustrating to use going forward.

To summarize the benefits of this over current b9stool:

  • No risk of something going wrong when running b9stool with CFW already installed, as long as OTP is found
  • One b9stool version supports almost all native firm versions, and is unlikely to need to be updated in the event of a native firm update
  • Users can safely use b9stool on a9lh, and don't have to do anything weird with launching it twice
  • The system is left with boot9strap in both firm partitions instead of just firm0, which is good for a few reasons
  • Less copyright violation I guess, as only a 0x200 block from native firm needs to be embedded. There are now also some boot9 keys though.

Credits

Advertising: