Hacking AL9H sd-less versioning

[nechigawara]

Since @raulpica splitting my discussion about A9LH version, I decide to change this topic into the thread explain the version of @Aurora Wright Arm9loaderhax. Remember, after 2.0, aurora-san doesn't give any release a version number. So people have the right to contiune using number version, or calling it as "Build" or subversion of v2 as you wish. This thread won't include forking version of her A9LH.

Beware!! Don't try older version of A9LH when you already on the lastest, unless you know what you trying to do.

Although I suggest everyone to update A9LH, only update it when important update is out. Because 1 A9LH update means you lose 1 NAND writting & Very Very low possibility of brick. You can update your A9LH by following this guide: https://3ds.guide/updating-a9lh

This thread start when @Alex658 asking me why I call A9LH CTRNAND as v4.

Just curious, what's is A9LH v4? If v3 is considered as sd-less (now known as CTRNAND cfw/luma)

According to GitHub page: https://github.com/AuroraWright/arm9loaderhax/releases
As of Nov 30, 2016, there are 5 version of Aurora Wright's Arm9loaderhax. 4 Official and 1 Unofficial

1. A9LHv1: https://github.com/AuroraWright/arm9loaderhax/releases/tag/v1 (Only Source Code Available)

This is the Initial release of her A9LH that came out. Can only be use with SafeA9LHInstaller 1.x. Nobody should using it right now because it's very outdated, small space for payloads, and no support anymore

Am I using this version?: If you install A9LH before June 2016 and never updating it, the chance is high that your console has A9LHv1. I don't know what time exactly when that the last version of v1 release. Well, although you have install v2 before june 2016, it will be outdated too if you never update it. Please update as soon as you can.

Another way to check is by taking out your SD card then booting your console. If the console is starting then shut itself down, no matter version installed, you should update.

2. A9LHv2: https://github.com/AuroraWright/arm9loaderhax/releases/tag/19/06 (Only Source Code Available)

This is the most popular version most 3DS was using. Can only be use with SafeA9LHInstaller 2.x up to v2.5. Changing in 8.1 FIRM allow more space for storing payload, allow more function can be include in payload. Although this was the most version people have in their console, it's also outdated. Because a 3DS with A9LHv1 or A9LHv2 can't boot if it can't find arm9loaderhax.bin on the root of SD card (By remove it SD card, deleteing, or have a problem reading SD card). People who still has it should update.

Am I using this version?: If you install/update A9LH from her github page between June 2016 and October 7, 2016, never touching it again, the chance is high that your console has A9LHv2. Please update as soon as you can.

Another way to check is by taking out your SD card then booting your console. If the console is starting then shut itself down, no matter version installed, you should update.

3. A9LH Experiment SDless Build: Unofficial version & this branch has been deleted.

Can only be use with SafeA9LHInstaller 2.x up to v2.5. This is an Experiment version that aurora-san try to add some features of CFW: firm0/1 protection, some simple FW patch, etc, into A9LH payload. Allow the 3DS to be able to boot even arm9loaderhax.bin file doesn't exist or can't be found at the boot time. Also, this version merge both Screen init & non Screen init function into one payload. The users can determine which one they want by changing arm9loaderhax.bin name. So no more seperate version.

Unfotunatly, this version has a problem with TWL Firm, make the console that has it installed without arm9loaderhax.bin having a problem running DS & DSi games. This build never release offially by herself, this version is not list on her github page. Still, people can install this version by complie from the source by themselves, or download the pre-compile from other users. Since this build has a big problem, and never officially support. People who still has it should update.

Am I using this version?: If you install/update A9LH from unofficial source (Reddit, some thread in gbatemp, etc) between June 21, 2016 and October 7, 2016, never touching it again, the chance is high that your console has Experiment SDless Build. Please update as soon as you can.

Another way to check is by taking out your SD card then booting your console while pressing select button. If the console is taking you to Home Menu, not Luma3DS configuration Menu, you should update.

4. A9LH ScreenMerge Build: https://github.com/AuroraWright/arm9loaderhax/releases/tag/6/10 (Only Source Code Available)

Can only be use with SafeA9LHInstaller 2.x. This is a version that aurora-san trying to change her way in achieving SDless boot. This version remove all of CFW features, change it back to make it has the same function as v2, except this version still retain both Screen init & non Screen init function in one payload, which can still determine by changing arm9loaderhax.bin name. Also, this version is the first one coming with .sha files which need in SafeA9LHInstaller v2.5.1 and up. Sometimes, I called this version v3.

Since this version has no difference from v2 except Screen init & non Screen init function. It's means this version still won't boot when console can't find arm9loaderhax.bin on the root of SD card. People who still has it should update. Although less people was using this one since not too long, the next version of A9LH is out.

Am I using this version?: If you install/update A9LH from her github page between October 7, 2016 and October 17, 2016, never touching it again, the chance is high that your console has ScreenMerge Build. Please update as soon as you can.

Another way to check is by taking out your SD card then booting your console. If the console is starting then shut itself down, no matter version installed, you should update.

5. A9LH CTRNAND Build: https://github.com/AuroraWright/arm9loaderhax/releases/tag/17/10 (Lastest Version)

Can only be use with SafeA9LHInstaller 2.x. This is result of aurora-san trying to make A9LH become SDless. This version has the all ScreenMerge Build functions. The difference is this version has ability to load arm9loaderhax.bin file from CTRNAND inside the 3DS when the console can't find arm9loaderhax.bin on the root of SD card. This mean when you're taking out your SD, if you install CFW that support this function inside CTRNAND, your 3DS won't auto shutdown and using CFW from CTRNAND instead. And this way won't effect TWL Firm like the Experiment build. I called this build as A9LHv4 sometimes. But because most people doesn't know that ScreenMerge Build is exist, they decide to calling this version v3.

Am I using this version?: If you install/update A9LH from her github page after October 17, 2016. You should have CTRNAND Build installed by now.

Another way to check is by taking out your SD card then booting your console while pressing select button. If the console is taking you to Luma3DS configuration Menu, not Home Menu, you have CTRNAND Build installed by now. Hooray, now you have the lastest version!!

Edit:: Fixd my misunderstanding, Change the thread to explain article, adding how to determine version you installed.
If my info was wrong, you can correct me by posting it in this thread. Thank You.

 

[OrGoN3]

If that was indeed the case, he's lucky he didn't have a N3DS or he would have a brick by now.

According to GitHub page: https://github.com/AuroraWright/arm9loaderhax/releases

• A9LHv1: Initial release.
• A9LHv2: Make it more safer to install
• A9LH SDless (Unofficial): Merge both Screen init and non Screen init into one, add internal CFW & firm0/1 protection. Has a problem with TWL Firm.
• A9LHv3: Remove internal CFW but retain Screen init + non Screen init merged & firm0/1 protection. Implement CTRNAND loader but not usable.
• A9LHv4: Full CTRNAND loader Function.

I don't know why people keep calling v3 CTRNAND since v3 release on Oct 7, an not fully support CTRNand, just preparing.

Except you're making that up. Nowhere on the GitHub page does Aurora use that terminology.

A9LHv1: initial payload
A9LHv2: larger payload

v4: refering to use of data_inputv4 when installing
A9LHv.2: referring to original SDLess booting of A9LH

Where are you getting your fake versioning from?

Edit: I get it. You're referring to each of her releases as a new version, even though she herself has not identified them in such a manner. And that data_inputv4 came much later than Aurora's fourth release of A9LH. I see where your flawed logic stems from now.

 

[nechigawara]

Except you're making that up. Nowhere on the GitHub page does Aurora use that terminology.

A9LHv1: initial payload
A9LHv2: larger payload

v4: refering to use of data_inputv4 when installing
A9LHv.2: referring to original SDLess booting of A9LH

Where are you getting your fake versioning from?

Then what was release on Oct 7, which CTRNand loader doesn't exist at that time?
It's doesn't the same version as v2 since this version merge both Screen init and non Screen init into one similar to SDless.
I have a proof about it since some body telling me in this forum when v3 come about CTRNand, I can digging it up for you if you want.

 

[OrGoN3]

Then what was release on Oct 7, which CTRNand loader doesn't exist at that time?
It's doesn't the same version as v2 since this version merge both Screen init and non Screen init into one similar to SDless.
I have a proof about it since some body telling me in this forum when v3 come about CTRNand, I can digging it up for you if you want.

Sure, go ahead and dig up a random person telling you about v2, v3, and v4. Unless it's from AuroraWright, it doesn't mean anything. Her v1 release listed v1 and her v2 release listed v2. Her releases since then did not list any version numbering. I see it as A9LH and A9LHv2, where v2 has support for larger payloads. The versions would determine which payload is required. The payloads between your supposed v3 and v4 did not change at all.

I can see how you and others use that terminology. I just haven't seen it used to refer to anything other than the data sets (beyond v2 that is). Also, why then did the data input sets versions not always match the A9LH version you are using? Data input v4 came about a week ago, yet according to your versions, A9LHv4 came out almost 2 months ago. See the discrepancy?

 

[nechigawara]

Sure, go ahead and dig up a random person telling you about v2, v3, and v4. Unless it's from AuroraWright, it doesn't mean anything. Her v1 release listed v1 and her v2 release listed v2. Her releases since then did not list any version numbering. I see it as A9LH and A9LHv2, where v2 has support for larger payloads. The versions would determine which payload is required. The payloads between your supposed v3 and v4 did not change at all.

I can see how you and others use that terminology. I just haven't seen it used to refer to anything other than the data sets (beyond v2 that is). Also, why then did the data input sets versions not always match the A9LH version you are using? Data input v4 came about a week ago, yet according to your versions, A9LHv4 came out almost 2 months ago. See the discrepancy?

I think data input version doesn't related to A9LH version, but rather related to SafeA9LHinstaller.

May be My suppose v3 is not a big update, less people know about it.
Also, the 3DS A9LH bible doesn't updating about it since it doesn't need people to update at that time.

Found it, also I'm sorry about CTRNand Implement, v3 only have Screen init and non Screen init merge and come with a hash.
This is my misunderstanding.
@AnalogMan is the one telling me the existance of v3, and his another post mention about CTRnand made me believe v3 has CTRNand Implement.
https://gbatemp.net/goto/post?id=6731113#post-6731113
https://gbatemp.net/goto/post?id=6731937#post-6731937

Well, if you mention @AuroraWright , then there is no v3 and v4 at all since she stop giving version number a long time ago.
Anyone can call version after v2 as they wish, like me who include Screen init and non Screen init merged which call the lastest v4,
Or yourself who decide to skip Screen init and non Screen init merge which call the lastest v3.

After this discuss, I think I should change how I call v3 and v4 to ScreenMerge Build and CTRNand Build instead.
So nobody would confuse and telling me making something up.

 

[Alex658]

I think data input version doesn't related to A9LH version, but rather related to SafeA9LHinstaller.

May be My suppose v3 is not a big update, less people know about it.
Also, the 3DS A9LH bible doesn't updating about it since it doesn't need people to update at that time.

Found it, also I'm sorry about CTRNand Implement, v3 only have Screen init and non Screen init merge and come with a hash.
This is my misunderstanding.
@AnalogMan is the one telling me the existance of v3, and his another post mention about CTRnand made me believe v3 has CTRNand Implement.
https://gbatemp.net/goto/post?id=6731113#post-6731113
https://gbatemp.net/goto/post?id=6731937#post-6731937

Well, if you mention @AuroraWright, then there is no v3 and v4 at all since she stop giving version number a long time ago.
Anyone can call version after v2 as they wish, like me who include Screen init and non Screen init merged which call the lastest v4,
Or yourself who decide to skip Screen init and non Screen init merge which call the lastest v3.

After this discuss, I think I should change how I call v3 and v4 to ScreenMerge Build and CTRNand Build instead.
So nobody would confuse and telling me making something up.

Actually, plailect's "bible" is updated almost as often as aurora's forks are. The official ones, of course. The guide won't include any nightly for obvious reasons.

 

[nechigawara]

Actually, plailect's "bible" is updated almost as often as aurora's forks are. The official ones, of course. The guide won't include any nightly for obvious reasons.

Well, those ScreenMerge Build doesn't beta or nightly version, since those release is require for that time because SafeA9LHinstaller need sha for hash checking.
But aside from Screen init and non Screen init merge and hash file, thers is no different from v2.

 

[OrGoN3]

I think data input version doesn't related to A9LH version, but rather related to SafeA9LHinstaller.

May be My suppose v3 is not a big update, less people know about it.
Also, the 3DS A9LH bible doesn't updating about it since it doesn't need people to update at that time.

Found it, also I'm sorry about CTRNand Implement, v3 only have Screen init and non Screen init merge and come with a hash.
This is my misunderstanding.
@AnalogMan is the one telling me the existance of v3, and his another post mention about CTRnand made me believe v3 has CTRNand Implement.
https://gbatemp.net/goto/post?id=6731113#post-6731113
https://gbatemp.net/goto/post?id=6731937#post-6731937

Well, if you mention @AuroraWright , then there is no v3 and v4 at all since she stop giving version number a long time ago.
Anyone can call version after v2 as they wish, like me who include Screen init and non Screen init merged which call the lastest v4,
Or yourself who decide to skip Screen init and non Screen init merge which call the lastest v3.

After this discuss, I think I should change how I call v3 and v4 to ScreenMerge Build and CTRNand Build instead.
So nobody would confuse and telling me making something up.

Listen, I want to apologize if I was harsh. I tend to be a bit harsher than needed without realizing it. This is all opinionated, so please continue to use the phrasing you are most comfortable with. I was simply attempting to explain my reasons for using the phrasing I use (yes, phrasing is back).

I see the v1 and v2 more relating to the payloads, or binaries, as mentioned before. A9LHv1 binaries compatible with SafeA9LHInstallerv1.x.x aren't compatible with SafeA9LHInstallerv2, and vice versa. the v2 binaries can be larger, SafeA9LHInstallerv2 uses the "perfect" key, and numerous other differences that I have no idea about.

Using that naming convention, I'd gather we'd see a SafeA9LHInstallerv3 with v3 payloads/binaries. This of course, is not necessarily true, just my way of thinking.

On top of Aurora not using versioning, I came to my conclusion. On the other hand, Aurora has 4 compiled releases of arm9loaderhax, with the first one marked as v1. She doesn't release a compiled version herself until a major change occurs (screeninit, ctrnand). There can be a few minor commits lingering and in the past, she has not updated (until something major occurred, also common with other developers). Using that logic, you can refer to them as v1-v4.

Personally, I refer to them as v1, v2 and then simply an updated build of Aurora's arm9loaderhax fork. Am I wrong? Perhaps. Do I base this on what I have seen here? Yes. Is it illogical to say that I have seen everything here, or that I have seen what every user has said here? Of course. My narrow crawlings of these forums may very well be hindering my understanding of any and all topics. However, until someone shows me definitive proof that they are v3 and v4 (aka Aurora mentioning it or Plailect giving us justification after changing his guide) then I will be stuck in my old ways.

Sorry to derail the topic.

 

[nechigawara]

Listen, I want to apologize if I was harsh. I tend to be a bit harsher than needed without realizing it. This is all opinionated, so please continue to use the phrasing you are most comfortable with. I was simply attempting to explain my reasons for using the phrasing I use (yes, phrasing is back).

I see the v1 and v2 more relating to the payloads, or binaries, as mentioned before. A9LHv1 binaries compatible with SafeA9LHInstallerv1.x.x aren't compatible with SafeA9LHInstallerv2, and vice versa. the v2 binaries can be larger, SafeA9LHInstallerv2 uses the "perfect" key, and numerous other differences that I have no idea about.

Using that naming convention, I'd gather we'd see a SafeA9LHInstallerv3 with v3 payloads/binaries. This of course, is not necessarily true, just my way of thinking.

On top of Aurora not using versioning, I came to my conclusion. On the other hand, Aurora has 4 compiled releases of arm9loaderhax, with the first one marked as v1. She doesn't release a compiled version herself until a major change occurs (screeninit, ctrnand). There can be a few minor commits lingering and in the past, she has not updated (until something major occurred, also common with other developers). Using that logic, you can refer to them as v1-v4.

Personally, I refer to them as v1, v2 and then simply an updated build of Aurora's arm9loaderhax fork. Am I wrong? Perhaps. Do I base this on what I have seen here? Yes. Is it illogical to say that I have seen everything here, or that I have seen what every user has said here? Of course. My narrow crawlings of these forums may very well be hindering my understanding of any and all topics. However, until someone shows me definitive proof that they are v3 and v4 (aka Aurora mentioning it or Plailect giving us justification after changing his guide) then I will be stuck in my old ways.

Sorry to derail the topic.

No, you're not wrong. Since she never give us version number anymore. So people have the right to call whatever they want.
I understand many people don't know the existance of ScreenMerge Build.
What I don't like is when the people telling me making somethings up although I said the truth.
I think that github page is enough to proof that there are already 4 official release of A9LH, not 3.

Well, at least I have to thanks you since this digging also make me realize some of my current misunderstanding too.
ScreenMerge Build doesn't have CTRNand Loader implement yet, just Screen Merge.
Still, I think it still should have FIRM protection since this build is an update version that just remove inner CFW from SDless build.
Edit: Checking current branch, patch.c already gone. So I will assume that there is no build-in FIRM protection anymore. Unless you install CFW on CTRNAND, no second layer FIRM protection.

Sorry to derail the topic, and sorry that I was also harsh on you too.

 

[raulpica]

Split from another thread since all of this was off-topic.

 

[nechigawara]

Changing this thread to be an explanation about A9LH version.
If my info was wrong, you can correct me by posting it in this thread. Thank You.

 

[OrGoN3]

Since @raulpica splitting my discussion about A9LH version, I decide to change this topic into the thread explain the version of @Aurora Wright Arm9loaderhax. Remember, after 2.0, aurora-san doesn't give any release a version number. So people have the right to contiune using number version, or calling it as "Build" or subversion of v2 as you which. This thread won't include forking version of her A9LH.

This thread start when @Alex658 asking me why I call A9LH CTRNAND as v4.


According to GitHub page: https://github.com/AuroraWright/arm9loaderhax/releases
As of Nov 30, 2016, there are 5 version of Aurora Wright's Arm9loaderhax. 4 Official and 1 Unofficial

1. A9LHv1: https://github.com/AuroraWright/arm9loaderhax/releases/tag/v1 (Only Source Code Available)

This is the Initial release of her A9LH that came out. Can only be use with SafeA9LHInstaller 1.x. Nobody should using it right now because it's very outdated, small space for payloads, and no support anymore

2. A9LHv2: https://github.com/AuroraWright/arm9loaderhax/releases/tag/19/06 (Only Source Code Available)

This is the most popular version most 3DS was using. Can only be use with SafeA9LHInstaller up to v2.5. Changing in 8.1 FIRM allow more space for storing payload, allow more function can be include in payload. Although this was the most version people have in their console, it's also outdated. Because a 3DS with A9LHv1 or A9LHv2 can't boot if it can't find arm9loaderhax.bin on the root of SD card (By remove it SD card, deleteing, or have a problem reading SD card). People who still has it should update.

3. A9LH Experiment SDless Build: Unofficial version & this branch has been deleted.

Can only be use with SafeA9LHInstaller up to v2.5. This is an Experiment version that aurora-san try to add some features of CFW: firm0/1 protection, some simple FW patch, etc, into A9LH payload. Allow the 3DS to be able to boot even arm9loaderhax.bin file doesn't exist or can't be found at the boot time. Also, this version merge both Screen init & non Screen init function into one payload. The users can determine which one they want by changing arm9loaderhax.bin name. So no more seperate version.

Unfotunatly, this version has a problem with TWL Firm, make the console that has it installed without arm9loaderhax.bin having a problem running DS & DSi games. This build never release offially by herself, this version is not list on her github page. Still, people can install this version by complie from the source by themselves, or download the pre-compile from other users. Since this build has a big problem, and never officially support. People who still has it should update.

4. A9LH ScreenMerge Build: https://github.com/AuroraWright/arm9loaderhax/releases/tag/6/10 (Only Source Code Available)

Can only be use with SafeA9LHInstaller 2.x. This is a version that aurora-san trying to change her way in achieving SDless boot. This version remove all of CFW features, change it back to make it has the same function as v2, except this version still retain both Screen init & non Screen init function in one payload, which can still determine by changing arm9loaderhax.bin name. Also, this version is the first one coming with .sha files which need in SafeA9LHInstaller v2.5.1 and up. Sometimes, I called this version v3.

Since this version has no difference from v2 except Screen init & non Screen init function. It's means this version still won't boot when console can't find arm9loaderhax.bin on the root of SD card. People who still has it should update. Although less people was using this one since not too long, the next version of A9LH is out.

5. A9LH CTRNAND Build: https://github.com/AuroraWright/arm9loaderhax/releases/tag/17/10 (Lastest Version)

Can only be use with SafeA9LHInstaller 2.x. This is result of aurora-san trying to make A9LH become SDless. This version has the all ScreenMerge Build functions. The difference is this version has ability to load arm9loaderhax.bin file from CTRNAND inside the 3DS when the console can't find arm9loaderhax.bin on the root of SD card. This mean when you're taking out your SD, if you install CFW that support this function inside CTRNAND, your 3DS won't auto shutdown and using CFW from CTRNAND instead. And this way won't effect TWL Firm like the Experiment build. I called this build as A9LHv4 sometimes. But because most people doesn't know that ScreenMerge Build is exist, they decide to calling this version v3.

Edit:: Fixd my misunderstanding, Change the thread to explain article.
If my info was wrong, you can correct me by posting it in this thread. Thank You.

Love it! Great work!!!!

 

[gnmmarechal]

Cool stuff. I differentiate them only between A9LHv1 and A9LHv2, with A9LHv2 splitting into several branches (Original, MiniCFW/LumaNAND, nocfw branch aka screeninit merge without built-in CFW, CTRNAND-loading A9LHv2).

When people start talking about A9LHv3, etc. I'm quite lost, as that's not an officially used term, and as such is difficult to know for sure you're talking about the same thing with someone else.

--------------------- MERGED ---------------------------

If you want, for whatever reason, binaries for various versions of A9LH, you can find them here: http://mirror.gs2012.xyz/3DS/A9LH/AuroraWright-A9LHv2/

Those are only A9LHv2. I've included some info about what file is what build here: http://gs2012.xyz/wiki/Aurora_Wright's_ARM9LoaderHax

Obviously, people aren't meant to try different builds without knowing what they're doing.

 

[nechigawara]

Adding how to determine version you installed.
Question, is there any CFW other than Luma3DS that support CTRNAND loader yet?

 

[OrGoN3]

Adding how to determine version you installed.
Question, is there any CFW other than Luma3DS that support CTRNAND loader yet?

I haven't seen one, but ShadowNAND has supported SDLess booting from NAND for quite some time.

--------------------- MERGED ---------------------------

Cool stuff. I differentiate them only between A9LHv1 and A9LHv2, with A9LHv2 splitting into several branches (Original, MiniCFW/LumaNAND, nocfw branch aka screeninit merge without built-in CFW, CTRNAND-loading A9LHv2).

When people start talking about A9LHv3, etc. I'm quite lost, as that's not an officially used term, and as such is difficult to know for sure you're talking about the same thing with someone else.

--------------------- MERGED ---------------------------

If you want, for whatever reason, binaries for various versions of A9LH, you can find them here: http://mirror.gs2012.xyz/3DS/A9LH/AuroraWright-A9LHv2/

Those are only A9LHv2. I've included some info about what file is what build here: http://gs2012.xyz/wiki/Aurora_Wright's_ARM9LoaderHax

Obviously, people aren't meant to try different builds without knowing what they're doing.

Same here. I see the A9LH and A9LHv2 as referring to the payload/binaries types more so than features. A9LH versioning would also then match the needed SafeA9LHInstaller version required for said binaries, along with using v2 payloads.

--------------------- MERGED ---------------------------

Split from another thread since all of this was off-topic.

Sorry for terribly derailing the other thread, and thank you for preserving our conversation.

 

[nechigawara]

I haven't seen one, but ShadowNAND has supported SDLess booting from NAND for quite some time.

ShadowNAND is A9LH CFW so I don't think it's related to this thread.
I just want to know if CFW that use A9LH exploit such as SaltFW or Corbenik has a way to launch from CTRNAND already or not.
Since right now, I only write how to determine A9LH version for Luma3DS only.

 

[OrGoN3]

ShadowNAND is A9LH CFW so I don't think it's related to this thread.
I just want to know if CFW that use A9LH exploit such as SaltFW or Corbenik has a way to launch from CTRNAND already or not.
Since right now, I only write how to determine A9LH version for Luma3DS only.

SaltFW hasn't been updated since June 26, so no.
Corbenik hasn't been updated since Aurora released Luma3DS's CTRNAND support. I do not believe it supported booting from CTRNAND. Looking at the latest commits, there are none regarding SDLess booting.