There is a thread about a legal open source 3DS Toolkit, sourced from here. It's presented as a "Work in Progress" 3DS SDK.
There are some things which need to be set straight. First of all, it's not an SDK, or on the way to becoming one. I am in no way affiliated with GaryOpa, he wrote the article without contacting me to clarify my intentions.
Just so you understand where I'm at, I started learning how to write computer programs last year. So I had an ambition to practice with tasks which caught my interest. Having a dev unit made re-implementing part of the 3DS SDK TOOLCHAIN, a desirable challenge. As the formats were, for the most part, documented. Re-implementing said tools had the added bonus of not having any restrictions imposed by Nintendo (ctr_makecia32 for example refuses to package CXIs, for which you didn't have the key). The other tools (like extdata_tool and rom_tool) do 3DS related tasks which are either not present in other tools, or (IMO) not done well enough in other tools.
"But why is it called CTR Toolkit if it's not an SDK? Are you trying to deceive us, inflate your ego, etc" No. "SDK" stands for "Software Development Kit". The name "CTR Toolkit" implies that it's a series of various 3DS tools. It doesn't imply that it can be used for developing homebrew. I chose the name "CTR Toolkit" in lieu of "3DS Toolkit", because I felt that those able recognise "CTR" as the code name for the 3DS, are more likely to be in a position where tools would be of use to them.
"Well then what does a homebrew 3DS SDK require?"
It would require Libraries(API for the developer), an ARM compiler, and perhaps a method for running the compiled code.
CTR Toolkit (ignoring that there's no Libraries or Compiler) provide (via the re-implemented SDK tools) only a part of the process "Official Developers", with access to "Development Kits" use to prepare the executable code into an acceptable form for the 3DS. (A process unfeasible to replicate on retail units without several RSA private keys, the AES key scrambler, AES keyX keyslots and KeyY calculating algorithms)
The other tools, well they aren't at all related making homebrew:
I thank those who defended/supported me/ctr_toolkit on the stark comments said on #3dsdev, but the truth is, it isn't and won't ever be an SDK. It'll take a better man than me to build 3DS libraries, and streamline a process for running homebrew. I apologise for any misunderstanding.
There are some things which need to be set straight. First of all, it's not an SDK, or on the way to becoming one. I am in no way affiliated with GaryOpa, he wrote the article without contacting me to clarify my intentions.
Just so you understand where I'm at, I started learning how to write computer programs last year. So I had an ambition to practice with tasks which caught my interest. Having a dev unit made re-implementing part of the 3DS SDK TOOLCHAIN, a desirable challenge. As the formats were, for the most part, documented. Re-implementing said tools had the added bonus of not having any restrictions imposed by Nintendo (ctr_makecia32 for example refuses to package CXIs, for which you didn't have the key). The other tools (like extdata_tool and rom_tool) do 3DS related tasks which are either not present in other tools, or (IMO) not done well enough in other tools.
Re-Implemented SDK Tools currently available in ctr_toolkit:
make_cia - re-implementation of ctr_makecia32
make_banner - re-implementation of ctr_makebanner32
"But why is it called CTR Toolkit if it's not an SDK? Are you trying to deceive us, inflate your ego, etc" No. "SDK" stands for "Software Development Kit". The name "CTR Toolkit" implies that it's a series of various 3DS tools. It doesn't imply that it can be used for developing homebrew. I chose the name "CTR Toolkit" in lieu of "3DS Toolkit", because I felt that those able recognise "CTR" as the code name for the 3DS, are more likely to be in a position where tools would be of use to them.
"Well then what does a homebrew 3DS SDK require?"
It would require Libraries(API for the developer), an ARM compiler, and perhaps a method for running the compiled code.
CTR Toolkit (ignoring that there's no Libraries or Compiler) provide (via the re-implemented SDK tools) only a part of the process "Official Developers", with access to "Development Kits" use to prepare the executable code into an acceptable form for the 3DS. (A process unfeasible to replicate on retail units without several RSA private keys, the AES key scrambler, AES keyX keyslots and KeyY calculating algorithms)
The other tools, well they aren't at all related making homebrew:
extdata_tool - A tool that handles and extracts data from decrypted extdata. Obtaining decrypted extdata requires the user to already have access to homebrew with kernel privileges.
make_cia_cdn - converts titles data from the form used when performing a System Update, to an installable CIA. Installing the CIA requires the user already be running homebrew to trigger the installation process.
iconcache_tool - extracts cached Icon data used by the home menu, from decrypted copy of home menu's extdata.
rom_tool - You know what that does.
I thank those who defended/supported me/ctr_toolkit on the stark comments said on #3dsdev, but the truth is, it isn't and won't ever be an SDK. It'll take a better man than me to build 3DS libraries, and streamline a process for running homebrew. I apologise for any misunderstanding.