Homebrew [Release] fastboot3DS - open source bootloader / chainloader

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 82,144
  • Replies Replies 233
  • Likes Likes 61
@Plailect just want a question... is there a chance of editing the 3dsguide website using this fastboot3ds insted of b9s which is i thing is more superior? thanks... :-)

"Fastboot3DS" is nothing more than a chainloader strapped to a sighax sig. It is objectively worse than boot9strap because it does not get pre-lockout bootrom code exec, and I cannot think of a single reason anyone would want to use it.
 
  • Like
Reactions: noctis90210
"Fastboot3DS" is nothing more than a chainloader strapped to a sighax sig. It is objectively worse than boot9strap because it does not get pre-lockout bootrom code exec, and I cannot think of a single reason anyone would want to use it.
Why do you would like bootrom code exec when you alreally have bootroms dumps?
 
@d0k3 thanks for the hint
https://m.imgur.com/a/jdx0x
jdx0x
 
  • Like
Reactions: d0k3

Attachments

  • IMG_4552[1].JPG
    IMG_4552[1].JPG
    983.7 KB · Views: 443
I have a suggestion: How about you add in a feature to rename the boot slots (ex. [slot 2] to [GM9] etc.)

Also...
I got dev features enabled
I guessed it on my first try :P
 

Attachments

  • IMG_20180201_043758.jpg
    IMG_20180201_043758.jpg
    935.2 KB · Views: 421
Last edited by Marioiscool246,
"Fastboot3DS" is nothing more than a chainloader strapped to a sighax sig. It is objectively worse than boot9strap because it does not get pre-lockout bootrom code exec, and I cannot think of a single reason anyone would want to use it.
That’s a rather condescending statement right there. I could personally think of several good reasons to use FB over B9S.
First, the user is allowed to pick and even switch boot priority for their payloads. FB does not set a default boot path nor require a default boot path. My 3DS for example has a boot.firm on the SD and NAND and I switch between them without conflict. Sure not everyone would use this feature, but it’s still an available feature for those who do want to use it.
FB has some basic NAND control features built in. This means not having to boot into GM9 to do basic tasks like NAND backup/restores. Again, not everyone would see the need for this, but it’s still a feature for those who do.
Dev mode has the option to boot payloads from FIRM1. Completely useless feature to most, but I had fun playing with it. Turns out you can boot any B9S payload from FIRM1 and it won’t have any ill effect on that payload.
You get all of those features, plus don’t lose support for B9S payloads.
You may not see a use for this, but there’s plenty of reasons why someone else would.
 
Last edited by The Catboy,
That’s a rather condescending statement right there. I could personally think of several good reasons to use FB over B9S.
First, the user is allowed to pick and even switch boot priority for their payloads. FB does not set a default boot path nor require a default boot path. My 3DS for example has a boot.firm on the SD and NAND and I switch between them without conflict. Sure not everyone would use this feature, but it’s still an available feature for those who do want to use it.
FB has some basic NAND control features built in. This means not having to boot into GM9 to do basic tasks like NAND backup/restores. Again, not everyone would see the need for this, but it’s still a feature for those who do.
Dev mode has the option to boot payloads from FIRM1. Completely useless feature to most, but I had fun playing with it. Turns out you can boot any B9S payload from FIRM1 and it won’t have any ill effect on that payload.
You get all of those features, plus don’t lose support for B9S payloads.
You may not see a use for this, but there’s plenty of reasons why someone else would.
x2
 
That’s a rather condescending statement right there. I could personally think of several good reasons to use FB over B9S.
First, the user is allowed to pick and even switch boot priority for their payloads. FB does not set a default boot path nor require a default boot path. My 3DS for example has a boot.firm on the SD and NAND and I switch between them without conflict. Sure not everyone would use this feature, but it’s still an available feature for those who do want to use it.
FB has some basic NAND control features built in. This means not having to boot into GM9 to do basic tasks like NAND backup/restores. Again, not everyone would see the need for this, but it’s still a feature for those who do.
Dev mode has the option to boot payloads from FIRM1. Completely useless feature to most, but I had fun playing with it. Turns out you can boot any B9S payload from FIRM1 and it won’t have any ill effect on that payload.
You get all of those features, plus don’t lose support for B9S payloads.
You may not see a use for this, but there’s plenty of reasons why someone else would.
You entirely misunderstand. It does not matter what features Fastboot3DS supports, as they are entirely unrelated to my point.

Sighax is an exploit, and boot9strap is an objectively better exploit. "Fastboot3DS" is just an application that uses an exploit. Much like Luma3DS or GodMode9, Fastboot3DS could be written to run under essentially any exploit (arm9loaderhax, sighax, boot9strap, etc), but the authors decided to have it only support standard sighax (likely due to scene politics related to the release of boot9strap). This means that replacing boot9strap with Fastboot3DS is objectively a downgrade from an exploit perspective (as you do not get boot9 code exec, and therefore cannot do things like dump boot9, boot11, and the OTP). A more sensible option would be for Fastboot3DS to run as a boot.firm under boot9strap, or for the authors to incorporate the open source boot9strap exploit into their application.

Why do you would like bootrom code exec when you alreally have bootroms dumps?

Boot9 code exec means we can avoid dealing with the legal fiasco of distributing Boot9, and instead allow anyone to dump it themselves using boot9strap. Fastboot3DS does not have the ability to do that because it uses an objectively worse exploit.
 
Last edited by Plailect,
You entirely misunderstand. It does not matter what features Fastboot3DS supports, as they are entirely unrelated to my point.

Sighax is an exploit, and boot9strap is an objectively better exploit. "Fastboot3DS" is just an application that uses an exploit. Much like Luma3DS or GodMode9, Fastboot3DS could be written to run under essentially any exploit (arm9loaderhax, sighax, boot9strap, etc), but the authors decided to have it only support standard sighax (likely due to scene politics related to the release of boot9strap). This means that replacing boot9strap with Fastboot3DS is objectively a downgrade from an exploit perspective (as you do not get boot9 code exec, and therefore cannot do things like dump boot9, boot11, and the OTP). A more sensible option would be for Fastboot3DS to run as a boot.firm under boot9strap, or for the authors to incorporate the open source boot9strap exploit into their application.



Boot9 code exec means we can avoid dealing with the legal fiasco of distributing Boot9, and instead allow anyone to dump it themselves using boot9strap. Fastboot3DS does not have the ability to do that because it uses an objectively worse exploit.
Would it be possible to include Boot9 code execution in fastboot3ds?
 
@d0k3 wait, so if I install this and use it to chainload GM9, I can use GM9's bootmenu? I know it doesn't make a ton of sense, but I'd like it that way. (What you said somehow doesn't make a lot of sense to me, perhaps you just have to say it again in a different way xD)
 
Boot9 code exec means we can avoid dealing with the legal fiasco of distributing Boot9, and instead allow anyone to dump it themselves using boot9strap. Fastboot3DS does not have the ability to do that because it uses an objectively worse exploit.

Okay, but my real question is, when you ALREALLY have you bootroms dumped with boot9stap, what is the point then to have then onto memory when you alreally have your OWN dumps on SD?
How can B9S objectively superior then FB3DS + your own dumps on SD?
 
Okay, but my real question is, when you ALREALLY have you bootroms dumped with boot9stap, what is the point then to have then onto memory when you alreally have your OWN dumps on SD?
How can B9S objectively superior then FB3DS + your own dumps on SD?
With bootstrap9, I'm free to take a dump whenever I please :)

Sent from my SM-G955F using Tapatalk
 
You entirely misunderstand. It does not matter what features Fastboot3DS supports, as they are entirely unrelated to my point.

Sighax is an exploit, and boot9strap is an objectively better exploit. "Fastboot3DS" is just an application that uses an exploit. Much like Luma3DS or GodMode9, Fastboot3DS could be written to run under essentially any exploit (arm9loaderhax, sighax, boot9strap, etc), but the authors decided to have it only support standard sighax (likely due to scene politics related to the release of boot9strap). This means that replacing boot9strap with Fastboot3DS is objectively a downgrade from an exploit perspective (as you do not get boot9 code exec, and therefore cannot do things like dump boot9, boot11, and the OTP). A more sensible option would be for Fastboot3DS to run as a boot.firm under boot9strap, or for the authors to incorporate the open source boot9strap exploit into their application.
I can agree that lacking those functions does actually make a difference, but my reply was more to the statement of, "a single reason anyone would want to use it," thus I listed reasons why someone would want to use it.
At the same thing, switching between FB3DS and B9S really takes like 30 seconds of one's time. So if someone really needs those bootroms and doesn't want illegally download them, they can switch back to B9S in only a few seconds. Hell they can even use your suggestion as just setting it to the boot.firm and keep B9S. At the same time not everyone really sees the reason to keep using B9S if they don't have to. I've already dumped my bootroms and OTP and even backed them up in multiple locations, I have no real reason to keep using B9S when FB3DS actually allows me to do more of what I do. Thus I use FB3DS over B9S because it's better suited for my setup and B9S just simply isn't for me.
 
Last edited by The Catboy,
Would it be possible to include Boot9 code execution in fastboot3ds?
Possible, yes, but incorporating the exploit has it's own disadvantages, one of them being that you could not chainload fastboot3DS from somewhere else anymore. Because dumping the bootroms is a one time affair, because dumping them is not relevant for end users in their daily use and because there is no homebrew (that I know of) that depends on pre-lockout execution, we decided against incorporating the exploit.

@d0k3 wait, so if I install this and use it to chainload GM9, I can use GM9's bootmenu? I know it doesn't make a ton of sense, but I'd like it that way. (What you said somehow doesn't make a lot of sense to me, perhaps you just have to say it again in a different way xD)
The GodMode9 bootmenu is exclusive to using GodMode9 as chainloader. So, sorry, no way to do that. Besides, the HOME menu inside GM9 is only sightly different from that.
 
@d0k3 three things. 1. We should be able to cancel NAND backups (definately not NAND restores though!), 2. We should be able to set the output for NAND backups, and 3. we should be able to exit dev mode, ideally the same way we got in.
 
  • Like
Reactions: Namesnipe

Site & Scene News

Popular threads in this forum