Hacking *cough* *cough*

  • Thread starter Thread starter Smiths
  • Start date Start date
  • Views Views 4,421
  • Replies Replies 24

Smiths

AKAIO Person of Interest TAGS ARE THE BEST
Developer
Joined
Feb 24, 2003
Messages
1,463
Reaction score
320
Trophies
2
Location
The land of Dairy Queen
Website
www.gamergeddon.com
XP
2,434
Country
United States
clipboard9yg5.jpg
 
NOWWWWWWWWWWW I have a useless AK2i on DSi
smile.gif


Do NOT use alternate loader support. I can use my AK2i on any other DS but on the DSi it now has the "can't load" screen.

Contacting acekard about a fix... figure something that needs to be run on a normal DS to flash the bootrom (if possible)
 
Smiths said:
NOWWWWWWWWWWW I have a useless AK2i on DSi
smile.gif


Do NOT use alternate loader support. I can use my AK2i on any other DS but on the DSi it now has the "can't load" screen.

Contacting acekard about a fix... figure something that needs to be run on a normal DS to flash the bootrom (if possible)
You... bricked it?
unsure.gif


That's scary stuff... I hope the AceKard Team will fix all of the soon, because this shouldn't happen of course
wink.gif
 
it's only "bricked" on a DSi (comes up with the error screen that any flash cart gets), so basically alternate loader flashed over the "bypass" thing.

This is also just a big thing the AceKard team should be prepared for, as all Nintendo has to do is have code in place to overwrite this code on flashcarts.

I can use my AK2i on my regular phat DS.

A rudolph tool dump of my AK2i has it identical to the "scene" release byte for byte, so this is kinda odd.
 
does this mean the dsi bootloader code is actually flashable from the acekard os then? potentially allowing for an update to circumvent any future attempts to lock it out on nintendo's part? or am i misunderstanding entirely
 
bollocks said:
does this mean the dsi bootloader code is actually flashable from the acekard os then? potentially allowing for an update to circumvent any future attempts to lock it out on nintendo's part? or am i misunderstanding entirely
It also means that Nintendo can release an update that checks for writable boot loaders and completely erase them which will basically brick the flashcarts so they won't work on any DS.
 
Narin said:
bollocks said:
does this mean the dsi bootloader code is actually flashable from the acekard os then? potentially allowing for an update to circumvent any future attempts to lock it out on nintendo's part? or am i misunderstanding entirely
It also means that Nintendo can release an update that checks for writable boot loaders and completely erase them which will basically brick the flashcarts so they won't work on any DS.

you really are very negative aren't you narin?

the bootloader is probably not writeable from the DS(i) itself, only on the acekard. it would be damn stupid electrical design to have the write enable pin connected to the DS directly.
 
Smiths said:
*cough* *cough*
You really should get that cough looked at...
tongue.gif


I presume Normatt has access to a method to dump the flash chip directly rather than relying on the header's rom chip size like the game dumpers do? Might have more to compare that way, from a working card instead of to the scene release which is far smaller than the 16Mbit chip it's on (that is also if the datasheet I'm looking at is the correct one.)
UltraMagnusthe bootloader is probably not writeable from the DS(i) itself, only on the acekard. it would be damn stupid electrical design to have the write enable pin connected to the DS directly.
The bootloader is on a chip that when you issue a specific set of commands to the DS card in the right order can have it's contents block erased, reprogrammed, or otherwise modified - it's just a PROM chip. It's also much more likely they'd try to blacklist based on other means that doesn't require sending multiple complex commands to every card inserted trying to erase 3rd party card firmwares.
 
AceKard's solution is to just send me more AK2i cards.
It's appreciated, but I'm still nervous. We'll be putting a boolean into AKAIO that detects if we're on a DSi and disables functions accordingly regarding alternate loaders.
 
To explain my reasoning: from my brief stint in the sources I do recall the RPG uses either the onboard flash or sram to stow file path information when transferring between the menu and the loader - I have speculated (to myself at least, I'm being far too lazy to verify this with a disassembler and my prods in you guy's direction didn't reveal the method) that ak2 may well be using a bank of the flash chip to do the same - if I'm right then data outside the initial loader (and again, the scene dump is definitely trimmed to the basic header/binary size in a tokyotrim fashion) is buggered on the non working card due to this and ak2i may well be expecting/using that data in some form of exploit to get around DSi limitations (kind of like they did with passme2, handing off the loading to an unexpected unprotected area.)

Any rate, if they are sending you a new deck of ak2is - what is there to be nervous about in experimenting on the semi-non-functioning one?
 
wait till i get my damn ak2is, ya bastard.
your plug is not the SOLUTION. solution is remove the options with a boolean. not let them choose an alt loader and have it go internally "HA HA NO!"
then we'll get "WHYZ I NO USE LATEST AK2 LOADERS KAN?"
 
Smiths said:
wait till i get my damn ak2is, ya bastard.
your plug is not the SOLUTION. solution is remove the options with a boolean. not let them choose an alt loader and have it go internally "HA HA NO!"
then we'll get "WHYZ I NO USE LATEST AK2 LOADERS KAN?"

It does use a boolean READ the bloody code! It also does an internal check so that if there was already a external loader selected then a specific game then it will use the default internal loader instead on the ak2i
 

Site & Scene News

Popular threads in this forum