[Rumor] Soundhax might be portable to DSi

Discussion in 'NDS - Emulation and Homebrew' started by Ryccardo, Dec 27, 2016.

Dec 27, 2016
  1. Platinum Lucario

    Member Platinum Lucario GBAtemp Regular

    Joined:
    May 17, 2014
    Messages:
    110
    Country:
    Australia
    At the same time, the DSi contains many new entry points in it's CPU as well. The DSi has four different kernels, compared to the DS (which only had two). DSi has ARM9, ARM7, ARM9i and ARM7i kernels. The ARM9i and ARM7i are the main kernels that are utilised when running the System NAND, DSi apps, DSiWare, DSi Exclusive and DSi Enhanced games. The TWL_SYSTEM NAND is completely different from the TWL_FIRM section of the 3DS NAND (because TWL_SYSTEM on DSi has ARM7 and ARM7i functions, since the 3DS doesn't have ARM7 or ARM7i kernels, the TWL_FIRM on the 3DS calls for a completely new emulated instruction set called "AGB_FIRM" , which again is not ARM7 or ARM7i).
     
    Last edited by Platinum Lucario, Jan 10, 2017
    Jayro likes this.


  2. metroid maniac

    Member metroid maniac An idiot with an opinion

    Joined:
    May 16, 2009
    Messages:
    1,572
    Country:
    United Kingdom
    Lack of interest.
    Besides, the attack surface for an absolute DSi hack is pretty small.
     
  3. OctopusRift

    Member OctopusRift GBATemp's Local Octopus, Open 9am-2am. "Not Yet"

    Joined:
    Nov 19, 2014
    Messages:
    1,457
    Country:
    Korea, North
    I am all for a revival. Might as well do it before the system loses online support in Feb.
     
  4. Ryccardo
    OP

    Member Ryccardo WiiUaboo

    Joined:
    Feb 13, 2015
    Messages:
    1,618
    Location:
    Imola
    Country:
    Italy
    3DS is Nintendo's first handheld with a real operating system, while the DSi has no actual background processes that could be exploited from an "userland" exploit

    Like with GBA/DS, all the system functions usable by applications are run directly from the unprotected bootroms or compiled by the sdk into the roms themselves

    Security on the DSi works with hardware registers you can't reenable without resetting (like why you must have 2.1 or less to read otp on 3ds), the launcher reads the header of applications to see what permissions they have (nand+sd? slot-1? camera? etc) tl;dr as you already know, you can't get nand access from an iEvolution so to get more permissions we would need to exploit home into accepting a custom title, the thing is that there aren't any public exploits in the boot chain that could lead to signature patching

    ---

    If the SDK can make retail-signed DSiware and roms (never tried) and get a friend at a bootleg game factory, we could create a physical copy of TWLNmenu and install itself (it being likely the only "official" app with both nand and slot1 access) and other tads...

    The same would be doable in a more ethical way with an existing DSiware exploit (implemented without #clobberedkeyslots) and a currently nonexisting homebrew title manager...


    -----

    Lol I really went off on a tangent here.
    Simply put: it's an objective fact the 3DS "security system" is more complex and fine grained.
    And it's exactly with complexity that the chance of screwing up increases!
     
    Last edited by Ryccardo, Jan 16, 2017 at 6:35 PM
  5. Platinum Lucario

    Member Platinum Lucario GBAtemp Regular

    Joined:
    May 17, 2014
    Messages:
    110
    Country:
    Australia
    Any application that has ARM9i/ARM7i kernel access (such as Nintendo DSi Sound and Nintendo DSi Camera) should be the ones to be exploited in order to gain full NAND access, as well as the SD card. No one knows where the exploits are, but the best way to find out... is to experiment and find ways it can be accessed.

    Any application installed on the NAND and run from the DSi Menu has access to the entire NAND, because otherwise if they didn't, apps like the Nintendo DSi Shop won't be able to install titles (which it installs directly to the internal NAND storage, unlike the 3DS which installs to the SD card only).

    The DSi is more of a system that closes one part of the NAND, then opens another section when needed. When running a game from a game card, it switches directly to it and closes the DSi Menu. But an app that's installed to the DSi, the DSi is still accessing the NAND, so it's still in use. Where as the 3DS is a system that runs two or more applications at the same time (eg. the Home Menu and the 3DS application/game). So in a nutshell, the DSi can only run one application, while the 3DS can run two or more applications.
     

Share This Page