Hacking What do the BootRates depend on?

  • Thread starter Thread starter Alex658
  • Start date Start date
  • Views Views 2,937
  • Replies Replies 33

Alex658

Well-Known Member
Member
Joined
Jun 4, 2010
Messages
1,206
Reaction score
385
Trophies
1
Age
31
Location
Colombia
XP
1,216
Country
Colombia
I've noticed between the different CFW/Entrypoints you can get really mixed results when coming to boot your emunand/CFW enviroment.

Palantine-PBT days bootrates through mset used to be around ~30%
mset-rxtools (either 2.6 or 3.0b) around ~90%
menuhax-rxtools 3.0b around ~80%

But recent cakes (first half of may) seems to be around ~45-50%
Haven't tried AuReiNand/Luma yet to confirm it's bootrate on my systems
I know for a fact A9LH enables a full 98-100% bootrate provided you have no menuhax leftovers and it's overall the maximum entrypoint of preference at this point in the cfw 3ds life.

What i want to know is more-or-less what does this entrypoints/cfw combinations rely on to give such bootrates.

I don't know if the term to be used is still ROP chains on how the exploit is executed into the payload, then the CFW.
 
it CAN'T. a bootrate of a thing should not be judged by another thing.

A 3ds with no CFW or without an entrypoint obviously has a bootrate of 0%. You can't hack a 3ds with no exploit, right?
The case about that little flaw that -sometimes- appeared in a9lh is about having two entrypoints conflicting one with another.
 
A 3ds with no CFW or without an entrypoint obviously has a bootrate of 0%. You can't hack a 3ds with no exploit, right?
The case about that little flaw that -sometimes- appeared in a9lh is about having two entrypoints conflicting one with another.
Menuhax is useless with a9lh ?!! So 100% bootrate with a9lh :-p
 
A 3ds with no CFW or without an entrypoint obviously has a bootrate of 0%. You can't hack a 3ds with no exploit, right?
The case about that little flaw that -sometimes- appeared in a9lh is about having two entrypoints conflicting one with another.

You don't need any other entrypoint when you have A9LH. That is of course when you already have it installed. But if you manage to boot menuhax each time when installing A9LH you'll have a 100% bootrate regardless.
 
A 3ds with no CFW or without an entrypoint obviously has a bootrate of 0%. You can't hack a 3ds with no exploit, right?
The case about that little flaw that -sometimes- appeared in a9lh is about having two entrypoints conflicting one with another.
the 3ds itself bootrate is 100%
 
this thread is mostly trash, sorry had to be said.... anyways, bootrates are where they are because of how the exploits work.... a race condition is literally a race to see who gets there first, and sometimes the timing is really tight (a lot of 3ds exploits are race conditions, actually)... other factors play in ofc, though I'm not sure all of them, though. @Filo97 is right about a9lh being 100% boot rate, the actual exploit (a9lh) booted, launched stage 1, stage 2 then booted into the 3ds OS... menuhax failing is not the fault of a9lh, it did it's job (booting a CFW, which then launches the 3ds OS) so saying "well a9lh failed, because menuhax failed to boot" is like saying "well, you did your job perfectly, but your buddy over there didn't, so you obviously failed your job"

Also @Ramzh the fact that you got to the bootscreen (I'm assuming that's a splashscreen, no?) means a9lh worked fine, but something else failed (like, maybe the SD card), so again, this is not the fault of a9lh and is like saying the statement above

saying "Cakes has a 45-50% bootrate" or whatever doesn't help us either. There are many entrypoints (MSET, browser(o3ds only), HBL, a9lh) so telling us which you use is the best way to go when talking about it...

Palentine had a terrible bootrate, yes, but for different reasons... simply, not much was known about the 3ds, and so, when they don't realize they're possibly overwriting important data (the stack, look it up if you want to know) it's pretty hard to get any sort of reliable bootrate

tl;dr: get your facts straight before posting in ANY thread anywhere :P
 
Last edited by dark_samus3,
Also @Ramzh the fact that you got to the bootscreen (I'm assuming that's a splashscreen, no?) means a9lh worked fine, but something else failed (like, maybe the SD card), so again, this is not the fault of a9lh and is like saying the statement above
I don't know actually there was the backlight on the screen that's it, and it was like that for around 20/30 secs, then I decided to shut it down and reboot and worked fine. The SD is a EVO+ new original and never had a problem I also check the SD sectors etc nothing:unsure:
 
I don't know actually there was the backlight on the screen that's it, and it was like that for around 20/30 secs, then I decided to shut it down and reboot and worked fine. The SD is a EVO+ new original and never had a problem I also check the SD sectors etc nothing:unsure:
backlight means screen init (which is in stage 2) ran, hence stage 2 ran. Meaning a9lh did it's job ;)
 
this thread is mostly trash, sorry had to be said.... anyways, bootrates are where they are because of how the exploits work.... a race condition is literally a race to see who gets there first, and sometimes the timing is really tight (a lot of 3ds exploits are race conditions, actually)... other factors play in ofc, though I'm not sure all of them, though. @Filo97 is right about a9lh being 100% boot rate, the actual exploit (a9lh) booted, launched stage 1, stage 2 then booted into the 3ds OS... menuhax failing is not the fault of a9lh, it did it's job (booting a CFW, which then launches the 3ds OS) so saying "well a9lh failed, because menuhax failed to boot" is like saying "well, you did your job perfectly, but your buddy over there didn't, so you obviously failed your job"

Also @Ramzh the fact that you got to the bootscreen (I'm assuming that's a splashscreen, no?) means a9lh worked fine, but something else failed (like, maybe the SD card), so again, this is not the fault of a9lh and is like saying the statement above

saying "Cakes has a 45-50% bootrate" or whatever doesn't help us either. There are many entrypoints (MSET, browser(o3ds only), HBL, a9lh) so telling us which you use is the best way to go when talking about it...

Palentine had a terrible bootrate, yes, but for different reasons... simply, not much was known about the 3ds, and so, when they don't realize they're possibly overwriting important data (the stack, look it up if you want to know) it's pretty hard to get any sort of reliable bootrate

tl;dr: get your facts straight before posting in ANY thread anywhere :P


Well, that's what i was asking exaclty.
Tried on 3 o3ds.
All i've ever used as entrypoints have been mset 4.1 RxTools2.6-3.0b (NANDs unlinked) and
menuhax 9.2 hbl (nands linked)-> cakes (early may build)

It's not that i don't check my facts, it's that i've read a lot about the exploits but haven't seen this exact part compared/covered or properly documented as to how much time each "race" of the exploit needs to take to succed.

I believe i never stated anything as a fact rather than just wanting some insight from people that do know how these work.

I do find it something amusing to be reading and learning about.
 
Like i said, a9lh can fail if you got menuhax interfering, or so i've read here in more than one instance. That's the only reason why i take 2% of it.
This has nothing to do with your stats. A9LH works 100% of the time and if menuhax fails after A9LH worked, that's menuhax's fault, not A9LH's, so don't remove points to A9LH because of this...
 
I actually agree with the 98-100% a9lh bootrate thing, It tends to work most of the time but like every few weeks-months I get a black screen and have to hold the power button
 

Site & Scene News

Popular threads in this forum