Hacking [WIP] KARL3DS - Kernel access on N3DS via Ninjhax + Loadcode

  • Thread starter Thread starter Rokkubro
  • Start date Start date
  • Views Views 936,725
  • Replies Replies 4,457
  • Likes Likes 43
Status
Not open for further replies.
That's a shame... But I don't see a reason why they wouldn't release it unless it interferes with their DRM. And there's always the fact that you would actually need a CN or OOT to install this but then again it would be much easier.
 
That's a shame... But I don't see a reason why they wouldn't release it unless it interferes with their DRM. And there's always the fact that you would actually need a CN or OOT to install this but then again it would be much easier.
yeah im pretty sure they will just adopt this approach no reason not to apart from random people crying copy cats....but who cares really karl3ds borrowed methods from gateway, no harm in gateway borrowing something back, both teams are happy gateway have a more user friendly entry point, karl3ds have the exploits gateway used in the first place.....i would say its square at that point
 
yes it will be exactly like how gateway on 4.x works, install profile exploit, go to DS profile and your in....launch NDS games and you need to install profile exploit again

depends if they downgrade TWL_FIRM too....should be possible i assume, but wait to hear from the karl3ds devs
Only if you run DS games on sysNAND will you need to reinstall the exploit.

Why you'd need to run anything on sysNAND after setting up an emuNAND I don't know.
 
they'd need to mess with dsi mode to re-enable the acecard. mines in my DSL still, working great.
yeah if they downgrade TWL_FIRM even more flashcards would be unblocked than just downgrading the whitelist....which would include the acekard2i.....assuming downgrading TWL_FIRM doesnt cause issues on the n3DS....but i see no reason why it would
Only if you run DS games on sysNAND will you need to reinstall the exploit.

Why you'd need to run anything on sysNAND after setting up an emuNAND I don't know.
well because at least with gateway you cant play NDS games in emunand....only way to play them is in sysnand
 
yeah if they downgrade TWL_FIRM even more flashcards would be unblocked than just downgrading the whitelist....which would include the acekard2i.....assuming downgrading TWL_FIRM doesnt cause issues on the n3DS....but i see no reason why it would

well because at least with gateway you cant play NDS games in emunand....only way to play them is in sysnand
Yep, that was my point.

With the way it's being implemented by roxas (assuming it's the same way as KARL) you'll be able to play DS carts in emuNAND, so there's no reason to be running them on sysNAND.

Edit: Derp, this is the KARL thread.
 
Im sure theyve been sitting on that one for a while now since theyre more than capable regarding coding so Im not really worried about that. What bothers me is the fact that Im not sure how the new MSET works? I mean lets say could you still install the gw file with a DS flashcard and then use it as you would in 4.x or what? :wacko:
No. Why? Because, gateway's 4.x ROP isn't set up for anything above 4.x. You'd need to write a new one to use the newer exploits.
But it would still be the same to an end user. Launch Settings->Start DS Profile->Magic Happens->CFW
 
  • Like
Reactions: Margen67
yeah if they downgrade TWL_FIRM even more flashcards would be unblocked than just downgrading the whitelist....which would include the acekard2i.....assuming downgrading TWL_FIRM doesnt cause issues on the n3DS....but i see no reason why it would

well because at least with gateway you cant play NDS games in emunand....only way to play them is in sysnand

n3DS TWL_FIRM uses the same titleID as the normal 3DS, so both use the same TWL. So logically you can probably downgrade it to TWL_FIRM from 1.0 and have it still work. But first we'd need a way of downgrading. I'm surprised no one has yet to hack the downgrade packs yet. I would like to try see if 1.0 TWL_FIRM will work on 9.2... :P
 
n3DS TWL_FIRM uses the same titleID as the normal 3DS, so both use the same TWL. So logically you can probably downgrade it to TWL_FIRM from 1.0 and have it still work. But first we'd need a way of downgrading. I'm surprised no one has yet to hack the downgrade packs yet. I would like to try see if 1.0 TWL_FIRM will work on 9.2... :P

Well that's completely wrong. New3DS has forks of every FIRM.
 
It does? My bad. I hadn't seen the title list for n3DS lately. So I guess downgrading TWL probably won't work on the n3DS. But then again, you guys did manage to downgrade the system settings app. Does that one have a separate title for n3DS?

EDIT:

Just checked. It is indeed a separate title. System settings appears to have the same TitleID from both. But n3DS definitely has it's own version. Odd.

TWL is handled entirely in Arm9 I think. Thus the extra encryption of Arm9 might impact TWL_FIRM partition. Even if one could install old TWL it probably won't work. And because the titleIDs are different the old version won't be used. Unless you uninstall the other one. But NATIVE_FIRM is probably expecting TWL with a the n3DS specific Title ID. I highly doubt we'll be able to downgrade TWL_FIRM to anything older then the first available version of TWL on the n3DS. System Settings worked, because the title IDs are the same for both platforms.
 
It's not odd at all, it's a new hardware platform with extra cores to handle, a slightly different NAND layout and different encryption in various areas.

The ARM9 binary encryption would not be a problem... there's a million other things that would go wrong when attempting to boot old 3DS FIRM.
 
add them to your ignore list.

omg! YES!

Will the devs in this topic who are doing such good work also please ignore these ungrateful pushy assholes? I would rather not see their negativity bring you guys down, having it affect your process. The last thing I want is for someone on the team to finally get fed up and drop out of the project because of some impatient shithead's whining.
 
It's not odd at all, it's a new hardware platform with extra cores to handle, a slightly different NAND layout and different encryption in various areas.

The ARM9 binary encryption would not be a problem... there's a million other things that would go wrong when attempting to boot old 3DS FIRM.

No I said that System Settings not having it's own title ID on the CDN list for the n3DS was odd: http://yls8.mtheall.com/ninupdates/reports.php

Of coarse it's not odd that it would be different on the n3DS because there's the "Super-Stable 3D" setting and the addition of the MicroSD Transfer app (which turned out to be it's own title. Which makes me curious. Does Data Management have it's own title ID? If so, there's stuff I'd like to experiment with that. :P )

I'm just curious as to how the CDN knows which version of System Settings to download in that regard.


Everything else you referred to is perfectly understandable and I agree. ;)
 
It does? My bad. I hadn't seen the title list for n3DS lately. So I guess downgrading TWL probably won't work on the n3DS. But then again, you guys did manage to downgrade the system settings app. Does that one have a separate title for n3DS?

EDIT:

Just checked. It is indeed a separate title. System settings appears to have the same TitleID from both. But n3DS definitely has it's own version. Odd.

TWL is handled entirely in Arm9 I think. Thus the extra encryption of Arm9 might impact TWL_FIRM partition. Even if one could install old TWL it probably won't work. And because the titleIDs are different the old version won't be used. Unless you uninstall the other one. But NATIVE_FIRM is probably expecting TWL with a the n3DS specific Title ID. I highly doubt we'll be able to downgrade TWL_FIRM to anything older then the first available version of TWL on the n3DS. System Settings worked, because the title IDs are the same for both platforms.

Old TWL won't work since ARM11 will hang without the extra cores having code to run, more or less. Also TWL isn't handled completely on ARM9. ARM11 is used to simulate the DSi's ARM9 and ARM7 cores (as far as we're aware). The (physical) ARM9 runs process9 like always.
 
omg! YES!

Will the devs in this topic who are doing such good work also please ignore these ungrateful pushy assholes? I would rather not see their negativity bring you guys down, having it affect your process. The last thing I want is for someone on the team to finally get fed up and drop out of the project because of some impatient shithead's whining.

I doubt they care, they seem to be at least 15 years old so can handle criticism and get on with their lives.
 
What is actually known about the bootloader? I just remember old Wii days, being able to do NAND backups from bootloader and experimenting on sysNAND without any fear.
Is anybody attempting to access the bootloader?
Automatic boot to emuNAND would already be awesome.
 
  • Like
Reactions: Margen67
The first thing the bootloader does is jump to the sekrit part at 0xFFFF8000. Said part is permanently disabled when the bootloader is done.

This will take hardware-level attacks. Unless it's possible to execute code before the bootloader sekrit area is disabled.
 
The first thing the bootloader does is jump to the sekrit part at 0xFFFF8000. Said part is permanently disabled when the bootloader is done.

This will take hardware-level attacks. Unless it's possible to execute code before the bootloader sekrit area is disabled.

It's not possible to execute code before because it's bootrom itself that disable this region.
The earliest code execution will could ever get is pre-ARM9 kernel... (oh, we have !)

BTW, I am wondering what SYSPROT9 actually does...
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum