you can use the browser with auto-load feature to acts almost like haxchi. it'll autoload the exploit and go into HBL directly, no link to press. of course, you lose the usage of the browser, but you can reset the autoload feature to get the normal browser usage.
the only difference is that you don't have the config.txt and button combo to do homebrew shortcut, you have to actually launch these homebrew manually.
haxchi : haxchi -> HBL
browser : browser-> HBL
see, identical, one click to hbl
from HBL, you can select "sigpatch2sysmenu" to patch signature and return to menu and launch a game, or "sigpatch2hbl" to patch signature and stay in hbl (to install a game).
Now, if you want detailed explanation why haxchi work with NDS and not with any other apps :
all apps contains 3 folders:
code/
content/
meta/
all the applications are located in /code/, and the folder is signed and checked at launch. it can't be patched or hacked.
content/ contains (usually) very small data used by the app, like some pictures, sound, etc., nothing active which runs and affects the processor. this folder is not signed.
meta/ contains info (game name, titleID, game icon, etc.), it's also not signed.
To launch an unsigned/patched program, you'd need to edit the program located in /code/ but the console verify if it's signed, and therefore wouldn't launch it if you don't already have CFW (which haxchi will do, you don't have CFW before launching haxchi).
It works with NDS games because nintendo placed a ROM inside the content/ folder.
the emulator is in code/ untouched and signed, so the console verify if the file is the correct one and run the app without problem.
then the emulator loads the NDS rom.zip located in content/ which is not verified, and is actually haxchi ROM instead of the NDS ROM game.
haxchi is exploiting a vulnerability in the emulator's code, which makes the emulator crash the console and gain access to kernel. the exploit is inside the emulator, and not launched by the console. this is why the NDS game is required : the emulator in code is signed, loading an unsigned file in /content/ to make the emulator crash.
other app "could" be used if they could be crashed by loading active code from content (like a ROM playing with CPU/GPU), but like I said the content/ folder mainly contains static data (picture, sound). most app have protection against exploit from these type of file, tiff image buffer overflow is not possible, etc.
To use another app, you'd need an app which break after being loaded officially. only NDS and browser have been found with such vulnerability.
it doesn't mean other app don't have vulnerabilities too, but nobody found any.
You know, the DSI still has some new found released exploit, years later. it's just a matter of someone being interested enough in understanding and analyzing the program run on the console and notice a bug in nintendo's code which can be exploited.
you don't search an exploit, you find bugs if you know very well how the console works and see a developer made a mistake. it doesn't mean it can be exploited every time.
@
realtimesave:
@
The Real Jdbye:
