过时的任天堂3DS主菜单haxx，又名menuhax_C_Assembly_下载.zip

# menuhax is obsolete. This is menuhax, exploits for the Nintendo 3DS Home Menu. # Summary These exploits trigger during Home Menu startup. Although this triggers during Home Menu boot, this can't cause any true bricks: just remove the \*SD card if any booting issues ever occur(or delete/rename the main Home Menu [extdata](https://www.3dbrew.org/wiki/Extdata) directory). Note that this also applies when the ROP causes a crash(the installed exploit itself), like when the ROP is for a different version of Home Menu(this can also happen if you boot into a nandimage which has a different Home Menu version, but still uses the exact same SD data). In some(?) cases Home Menu crashes with this just result in Home Menu displaying the usual error dialog for system-applet crashes. # Old3DS return-to-menu On Old3DS with applications which trigger a firmlaunch due to requiring more memory for the APPLICATION memregion, pressing the HOME button will result in a hang due to Home Menu crashing with menuhax installed. This include Super Smash Bros, Monster Hunter as well as Pokemon Sun and Moon. The only way this could ever be resolved is with a Home Menu vuln which doesn't involve linearmem pre-\*hax-payload, unlike all of the ones used in this repo publicly currently. # Vulns * themehax: The original vuln for this repo was discovered on December 22, 2014. This flaw was introduced with the Home Menu version which added support for themes: 9.0.0-X on Old3DS, v8.1 on JPN-New3DS. Old3DS JPN theme support was "added" 9.1.0-XJ. The release date for this exploit was September 25, 2015. * shufflehax: The vuln for this was discovered on January 3, 2015. The shufflehax exploit itself was finally implemented in December 2015, it was finished on the 7th-8th. The release date for this exploit was on December 27, 2015, in US-time. https://events.ccc.de/congress/2015/Fahrplan/events/7240.html Exactly one week later from release-date would be exactly one year since the vuln was discovered. Theme-shuffling and this vuln were introduced with 9.3.0-X. * sdiconhax: For vuln details, see source and [here](https://www.3dbrew.org/wiki/3DS_Userland_Flaws). This was exploited in June 2016. * bossbannerhax: For vuln details, see source and [here](https://www.3dbrew.org/wiki/3DS_Userland_Flaws). This was exploited in December 2016. ## Vuln used with themehax Home Menu allocates a 0x2a0000-byte heap buffer using the ctrsdk heap code: offset 0x0 size 0x150000 is for the output decompressed data, offset 0x150000 size 0x150000 is for the input compressed data. Immediately after this buffer is a CTRSDK heap freemem memchunkhdr, successfully overwriting it results a crash(when the data written there is junk) in the CTRSDK heap memchunk handling code with the linked-lists. The decompression code only has an input-size parameter, no output size parameter. Hence, the output size is not restricted/checked at all. Since the decompressed data is located before the compressed data, the buf overflow results in the input compressed data being overwritten first. Eventually this overflow will result in the input data actually being used by the decompression function being overwritten, which can later result in an error before the function ever writes to the CTRSDK memchunk-hdr(if the input compressed data doesn't workaround that). ## Vuln used with shufflehax Hence the name, this is a vuln with theme-data loading for theme-shuffling. Home Menu does a file-read from extdata for loading the compressed input-theme-data, with a size field loaded from extdata ThemeManage. This size is not validated at all. ## Vuln fix sysupdate(s) * The 10.2.0-X sysupdate [fixed](https://www.3dbrew.org/wiki/10.2.0-28) the vuln with theme decompression(themehax). * The 10.6.0-X sysupdate [fixed](https://www.3dbrew.org/wiki/10.6.0-31) shufflehax. * The 11.1.0-X sysupdate [fixed](https://www.3dbrew.org/wiki/11.1.0-34) sdiconhax. * The 11.3.0-X sysupdate [fixed](https://www.3dbrew.org/wiki/11.3.0-36) bossbannerhax. # Usage notes for sdiconhax With sdiconhax installed, when Home Menu does a normal boot all writes to extdata SaveData.dat are blocked. This is only for normal boots, not when \*hax payload was booted *from* menuhax. This *had* to be blocked because the haxx data was getting reset every time Home Menu wrote to this file. This blocks *anything* from being done with this file, hence you can't run menuhax-install/deletion with this unless you booted \*hax payload from menuhax. Also note that you can't do/use any of the following without Home Menu entering a crash-boot-loop: exit from hbmenu for returning to Home Menu, menuhax-thread hax-payload boot(due to restarting homemenu), or returning from any system-applets on Old3DS(web-browser etc). This will also happen when a regular-application crashes when trying to return to Home Menu. Basically, anything that causes the Home Menu process to restart. If you use the menuhax-thread keycombo, the non-icon-data areas of SaveData.dat will be written to FS prior to terminating the process, however see above regarding this thread. This is mostly useful for when you changed theme-settings. Icon-related data is not saved because the written data would be reset anyway, and the haxx didn't trigger properly. Due to the above, you can't change anything related to SD icon layout(including presents) and have it persist after a Home Menu process restart. You can only do so when sdiconhax isn't installed(uninstall, change layout, then install again). Deleting/renaming the main Home Menu extdata directory will of course reset this SD icon layout data. If you enter the power-off screen then return to Home Menu, the icon layout will be reset with presents however this will not be saved to FS. Do not change the system language with System Settings with sdiconhax installed. If you do so, you will have to delete the Home Menu extdata as mentioned in the Summary section above. # Usage notes for bossbannerhax This is used for system-version v11.1-v11.2. This does not trigger during Home Menu boot. This triggers when the Face Raiders icon is selected by the user, which triggers loading the exbanner data(Face Raiders is just the ideal target title for this among the system titles with exbanner-usage enabled). The usual PAD-config for actually running it still applies. Normal {return to homemenu code} is not supported with bossbannerhax. It will terminate Home Menu via svcExitProcess instead, resulting in the usual crash message. This doesn't matter much since the exploit only triggers when selecting the icon listed above. For deleting bossbannerhax you should use menuhax_manager. But if you really want to delete it manually, even though face-raiders BOSS data(non-hax-data) won't be completely deleted, you can manually delete the Face Raiders extdata(you could even do this with System Settings if you want). Nothing else on SD is required for bossbannerhax deletion. For installing bossbannerhax, either ctr-httpwn >=v1.2(with bosshaxx) must be already active, or the system must be running "CFW" with sigchecks patched. # Supported System Versions As of menuhax v3.2, system-versions 9.0.0-X..11.2.0-X are all supported. During installation it automatically detects which exploit to install. See also the above sections. Note that as of November 2016 [bossbannerhax](https://www.3dbrew.org/wiki/3DS_Userland_Flaws) was the last known Home Menu vuln. The initial release archive only supported USA, EUR, and JPN. TWN and CHN aren't supported currently. KOR builds which are *actually* usable are included starting with v3.0, via sdiconhax for 9.6.0-X..11.0.0-X(the theme-data exploit KOR builds were removed since themes aren't actually usable with KOR). # Building See Building.md. # Usage Just boot the system, the haxx/initial-ROP will automatically trigger while Home Menu loads. Prior to v2.0 Home Menu attempted theme-loading when returning from the power-off screen, however since Home Menu stat