NeoFlash Private Source Released

[Zeus]

Here we have a leaked version of the NeoFlash tool source code for you. Hope you like it ;). Expect more from us in the future..

Discuss this release here and you can read more in the nfo file.

[whackawookie]

is the actual attachment supposed to be here or just the nfo? still excellent news.

[DarkCube]

best news ive heard all day :D

[phantomdjp]

Private Source ? Not so private, they give it to every "good dev" who have got a free Neoflash.
And it's useless since it don't have anything really interesting to dump or start NDS roms...
The only "fun" things is that the true name of Neoflash is "XG3 Flash" ... not a surprise...

[DarkCube]

the source is the source code for the program, aka it contains the source code for the loader, which can be ripped, recompiled, removed all the damn encryption and made to run on ANY flash cart.

[cory149]

DarkCube, there is no NEO ndsloader, just a dll to tell the app what to do wiht extensions like nds and neo. As far as I can tell there is no encryption present in the neokit, but the last time I looked it was at .91...

The gst roms do not appear to be encrypted, they just have ALL the FAT addresses in the filesystem and binaries patched/altered to load from the gba slot instead of the ds slot, which are also hardwired into the XG"3" cart, aside from the savegame which is still mapped to the nds slot. Likely the neokit will not see a multibooter capable of loading 2 separate commercial roms off the gba cart because of the static locations patched in.

If anything, the default bootloader in the roms has been changed slightly to detect a special revision of the PASSME called NEOKEY.

I still have no clue how to reverse the damage done to the roms to proove without a doubt to myself that this is what has been done...

At any rate, nice nfo file, where is the download?

[whackawookie]

u know whats sad, once somebody finally removes the patch for neokey detection theyll either stop releasing dumps or hard code it more. this is not a scene contribution but a money hungry attempt to own the scene. funny how nothing else has been mention about the usb loader tool.

[cory149]

Ah well, I knew the leaked source would be nearly as tough to get as the official source...

[fRUiTDEV]

Originally posted by cory149
DarkCube, there is no NEO ndsloader, just a dll to tell the app what to do wiht extensions like nds and neo. As far as I can tell there is no encryption present in the neokit, but the last time I looked it was at .91...

The gst roms do not appear to be encrypted, they just have ALL the FAT addresses in the filesystem and binaries patched/altered to load from the gba slot instead of the ds slot, which are also hardwired into the XG"3" cart, aside from the savegame which is still mapped to the nds slot.
Likely the neokit will not see a multibooter capable of loading 2 separate commercial roms off the gba cart because of the static locations patched in.

If anything, the default bootloader in the roms has been changed slightly to detect a special revision of the PASSME called NEOKEY.

I still have no clue how to reverse the damage done to the roms to proove without a doubt to myself that this is what has been done...

At any rate, nice nfo file, where is the download?

I was wondering for a little while how the GST roms we're patched exactly.. this gives me a better insight view I gues.. :)

So if I understand correctly original NDS roms make use of the NDS filesystem and do all file acessing through that, while the GST patched roms have just hardcoded adresses to *somewhere* on the GBA cart. That would require quite some calculation I guess? Or do they just rip out all the start adresses from the FAT and add a certain value or something?

which are also hardwired into the XG"3" cart
I don't get this fully.. what do you mean by hardwired?

And why are the GST roms way bigger then the DFv2's? I can understand that some patching would get you some overhead, but not that much ;)

Did you ever look at the NDS header in the GST roms? they have very strange ARM7/ARM9 load addy's and such.. (totally impossible ones it seems to me)
And the "boot signature" is different too I believe. the normal PassMe works by searching for the "DSbooter" string in the header, but this one had a different one if I recall correctly (was a while ago when I last looked at this.. ;))

u know whats sad, once somebody finally removes the patch for neokey detection theyll either stop releasing dumps or hard code it more. this is not a scene contribution but a money hungry attempt to own the scene. funny how nothing else has been mention about the usb loader tool.
Like said above by corey, there probably isn't even a real check for the NEOKEY..

Anyhow, let's investigate this further so we can get our own patcher out (and make it work on all flashcarts offcourse) :D

PS. yay, my first maxconsole post ;-P

[cory149]

I think they have recursively patched all the addresses in the FAT as well as the code excepting the save eeprom locations. They would likely have been patched to GBA locations, the only thing I can think of that would explain the odd arm9/7 locations is if part of that was code that is interpreted by the XG cart, but I could be waaaay off on that and like darkfader seems to beleive they could very well be encrypted by GST, but I have my doubts about that.

It seems likely they have the aid of a DS dev machine with full debugging support.

As to the size difference, the DF dumps were decrypted and had left out sections of the ROM that were encrypted differently than the random number method. When unpacked from the zips both metroids (df and gst) come out to 16,777,216bytes.

Whether there is still all/enough of the data still in there to actually play the dump without the real cart present is beyond me, but I have read that it does play on the neoflash just without savegame support.

any idea where to start? I was thinking a stepping disasm may reveal somthing but I dont have the hardware/software to even think of doing such a thing...

[fRUiTDEV]

They would likely have been patched to GBA locations, the only thing I can think of that would explain the odd arm9/7 locations is if part of that was code that is interpreted by the XG cart
Hmm yes... I guess the XG cart features some kind of bank/adressing switching which get you the really odd adresses instead of the normal 0x80000000+ (iirc) addy's..

It seems likely they have the aid of a DS dev machine with full debugging support.
Im quite sure they (or he *wink*) doesn't :)

As to the size difference, the DF dumps were decrypted and had left out sections of the ROM that were encrypted differently than the random number method. When unpacked from the zips both metroids (df and gst) come out to 16,777,216bytes.
the sections you are talking about is the so-called "secure area" ?

Whether there is still all/enough of the data still in there to actually play the dump without the real cart present is beyond me, but I have read that it does play on the neoflash just without savegame support.
The GST dumps play on an ordinary XG2 + regular Passme too.. so I think it would be something hardware specific on the XG2/XG3 hardware side, or in the flasher software.. But also confirmed is, that if you flash the GST roms using the XG2 flasher (not neoflash software) it also works on a regular Passme + XG2. :)

any idea where to start? I was thinking a stepping disasm may reveal somthing but I dont have the hardware/software to even think of doing such a thing... Well, you could disasm the ROMs using a ARM disassembler. rip off the NDS/GBA header and chop it into IDA :-) Oh wait, I believe there is a .NDS extension for IDA out.. (check DF's DS page)

[cubenoob]

Originally posted by fRUiTDEV

The GST dumps play on an ordinary XG2 + regular Passme too.. so I think it would be something hardware specific on the XG2/XG3 hardware side, or in the flasher software.. But also confirmed is, that if you flash the GST roms using the XG2 flasher (not neoflash software) it also works on a regular Passme + XG2. :)

So this means you can take a normal xg2 and use the flasher and a passme and you could play the roms? Dont get me wrong but several people around this forums stated that this method wont work. And some have tested it before and confirmed that this wont work.

But if this method works there´s no need for a neoflash at all and everyone could use a xg2 and the flasher with a passme? But I wonder why noone really uses this.

Another question is if you use the hacked firmware and flash it to the ds (i think it was called flashme) is this a replacement to the hardware passme?

[fRUiTDEV]

Originally posted by cubenoob
So this means you can take a normal xg2 and use the flasher and a passme and you could play the roms? Dont get me wrong but several people around this forums stated that this method wont work. And some have tested it before and confirmed that this wont work.
Yep, this has been tested by Acey- from 64scener.com. :)

But if this method works there´s no need for a neoflash at all and everyone could use a xg2 and the flasher with a passme? But I wonder why noone really uses this.
Indeed, there is no real need for Neoflash :)

Another question is if you use the hacked firmware and flash it to the ds (i think it was called flashme) is this a replacement to the hardware passme?
Yep, wifime is a replacement for the passme. It works in the same way (looks for a signature on the GBA flash, then run).

[cubenoob]

Oh thats great! Now I´m really only one click away from ordering an xg2 flash card. But I still have some more questions:

1. Should I buy an xg2 flash card?
2. What else do I need? I want to use the wifime and this is like you have a passme. So I´ll need a wireless pci card? I have no laptop and I heard only a few chipsets will work on this but I´m not sure if it was the other thing which was streaming the games from pc to ds.
3. What software to use to flash the new firmware and to flash the roms to the flashcard?

TIA

[cory149]

I have my doubts though, dshacker.com, that this is a real release, nevermind with any direct value to finding the method that the gst roms were patched...

Fruitdev: That said, after the first 2 dumps (metroid and mario64) the gst roms supposedly no longer work with flashme and possibly passme, but I havent verified this in person. The XG/passme combo is supposedly extremely picky about the cpld version that is used in the passme (by a guess, if any would work you'd be looking for the cpld code that enabled/uses the led just like the neokey has, removed from later revisions around the same time neoflash was announced)

the nds loader for ida 4.7 does not recognize the gst roms as valid nds files and I personally dont have the patience to dehack those releases anyways.

If you recall looking at them (gst releases) with ndstool then you would also remember not only are the addresses really weird but all the crcs failed. The loader is based on darkfaders work with ndstool, so without mods its kinda unlikely it will load roms with odd addresses to the binaries...

not sure how else one would learn to debug/patch a rom that large without being able to disasm it or live patch it in memory as its running. I really dont have the skill or desire to reverse the gst dumps, but am still interested in the unique solution that XG and GST came up with.

Its nearly as fascinating as that large/prototype passme that DF used way back when the DS was near impossible to get.

[Schnibblez]

Using the leaked source i reversed the header of the GST team dumped roms...
Im noticing references to 'bZip' in the code which is explaining that maybe they are compressed which would explain the jumbled look of them.


typedef struct _XGFILEHEADER {
DWORD dwJmpInst;
UCHAR NintendoLogo[0x9C];
UCHAR GameTitle[12];
DWORD GameCode;
WORD MakerCode;
UCHAR Const96H;
UCHAR MainUnitCode;
UCHAR DeviceType;
// XGFILEATTR is 7 bytes long.
XGFILEATTR XGFileAttr; // XGFile attribute area.
UCHAR MaskRomVersionNumber;
UCHAR ComplementCheck; // The 2's complement of the total of the data stored in offset A0h ~ BCh plus 19h is stored in this location.
// From GameTitle to XGFileAttr
XGFILEATTREX XGFileAttrEx; // XGFile attribute expanded area. reserved for future use.
// Now set to zero.
} XGFILEHEADER, *PXGFILEHEADER;

typedef struct _XGFILEATTR {
UCHAR uRomSizeLow; // Lower 8 bit size of ROM.
UCHAR uRomSizeHigh; // Higher 8 bit size of ROM.
UCHAR uRomOffsetNextLow; // all bit set to 0 means no rom after it.
UCHAR uRomOffsetNextHigh; // all bit set to 0 means no rom after it.
UCHAR uSaverSize; // Saver of rom in block.
UCHAR uFileAttr; // file attribute (low 4 bit), and Saver Type (upper 4 bit)
UCHAR uFunction; // function bit set to 1 means enable, 0 means disable.
} XGFILEATTR, *PXGFILEATTR;

typedef struct _XGFILEATTREX {
WORD wExFunction;
} XGFILEATTREX, *PXGFILEATTREX;

//Sample Analysis from Super Mario 64 DS GST dump


2E00 00EA //DWORD dwJmpInst;

24FFAE5144656D6F5F312E305375706572204D6172696F2036 342044
530A2020202020202020000000000000000000000000000000 000000
00000000000000000000000000000000000000000000000000 000000
00000000000000000000000000000000000000000000000000 000000
00000000000000000000000000000000000000000000000000 000000
00000000000000000000000000000000 //UCHAR NintendoLogo[0x9C];
//NOTE: GST seem to use this section to store data about the game, in this example it containing //'$..QDemo_1.0Super Mario 64 DS. ' maybe for neoflash or a custom tool to read??

532E4D4152494F3634445300 //UCHAR GameTitle[12]; (S.MARIO64DS.)
41534D45 //DWORD GameCode; (ASME)
3031 //WORD MakerCode; (01 - Nintendo)

96 //UCHAR Const96H;
00 //UCHAR MainUnitCode;
00 //UCHAR DeviceType;

07 01 06 00 00 00 00 //XGFILEATTR XGFileAttr;
00 //UCHAR MaskRomVersionNumber;
FF //UCHAR ComplementCheck;
00 00 //XGFILEATTREX XGFileAttrEx;

[cory149]

its entirely possible that they are using gZip to decompress roms directly from zip files instead of only flashing unzipped files (you can usually tell compression by seeing partial words in english in the hex/ascii that are only a little jumbled, but its not always that way as there has to be visible words in the uncompressed stuff)

that looks like (if not the same as) the standard header format - GST adds a GBA header in the very top, possibly to fool the neo loader for future support of loading both ds and gba games from the same cart.

I have to go back on my beleif that the dumps arent encrypted, had a revelation when I got up today.

I'm not sure at what point the standard game carts start encryption based on the random number/seed method discoverd by darkfader... but Im pretty certain that the header isnt encrypted so the arm9 and 7 locations should be correct (but arent?).

Encryption would also explain why the blank spaces in the DFv2 releases are not present in the GST releases, but I have no clue how they could put encrypted data into a ROM and get the DS to use it like its not garbage... unless they are dumping this stuff directly from hardware chips?

Perhaps they are using a fixed number to base the encryption on and have changed the number after the first two releases to prevent passme from allowing it to work correctly?

Thanks for the info you have uncovered Schnibblez, if you feel like sharing a source for the source it would be greatly appreciated as I cannot locate it in any of my usual places to look (pm if you do, if not I guess I'm hooched...):(

[Schnibblez]

I'm thinking that the actual xgflash cart itself has built in decoder/decompressor because the neoflash code has no rom changing abilty at all. ROM's come prepared for xgflash only which comes to one conclusion... neofla$h and gst = the same person.

[cory149]

likely, or paid off in hushkits, err neokits...

[webcrawler42]

i like this thread so i subscribed, this is my first maxconsole forums post. i just attached a fixed version of the nfo.

[cory149]

they both look the same in damn nfo viewer... welcome webcrawler42 :D

[brakken]

Cory! Check your darn Private Messages! :)

[cory149]

I thought I had notify turned on... :( seems there has been a couple, thanks!! :rolleyes:

edit in:/After a few bumps and bruises, I have concluded (with my own two eyes) that the code in a DS rom is likely packed when the filesystem is created, and that the code in a GST DS rom is encrypted in a way that the DS can still read the code, until it gets to the first call to the ROM physical address.

My latest harebrained theory as to why these work on a Neo and not others: bankswitched with the well documented xg carts bankswitching to the end of the header to make the calls valid, but the bankswitching would/should not work on other types of carts. And there is definitely some code that does read from the DS cart slot and puts stuff from there into memory before it gets to that call...of course I am likely wrong as the disassembler/emulator I am using is likely not reliable for this, but hey, a theory is a theory.

[webcrawler42]

im curious on how this works, will it be a loader on a flash card, like rewriting ezloader for ezflash carts or will it be a new form of passme, or will it be a firmware update, or even a loader that you flash as a .gba to your flash card that contains the .nds files, beacuse most flash carts wont take .nds only .ds.gba

[cory149]

Likely the best solution will eventually be a DS slot type cart, perhaps even like the dev cart for DS that sticks out like the NeoKey does, depends if anyone who would be doing the manufacture decides to crack open the encrypt method of the chip on game cards... till then it is likely that the games will need to be patched specifically for a specific flashcart's bankswitching if what I mention above prooves out... and with passme/flashme it really doesnt need a loader, it just needs to know that the cart contains DS bootable code, done with the header as far as I know (instead of ASME for super mario it would be PASS). Of course, its also likely that the bootloader in the roms by gst has been modified somewhat for this purpose as well so that no loader like what you append to a .nds to get a nds.gba is needed...

[fRUiTDEV]

Hmmm... I'm getting more interested in the CPLD code that's contained on the NeoKey. Maybe there's some differences compared with the original PassMe CPLD code. One could crack open the NeoKey and attach a homemade CheapTag JTAG cable (http://warmcat.com/milksop/cheaptag.html) and dump it using the Xilinx ICE pack (free) software from the Xilink website.. But I doubt anyone with a Neoflash is willing to crack open their Neokey to check this out for us hehe. :)

I took some more time to look at the GST roms and compare them to the DFv2's.. It really seems like the GST roms are encrypted. I check out how much each byte in the file occured, and this value averaged from 62000 to 68000 times (all 0x00-0xFF bytes are present). Furthermore there isn't even ONE place in the whole ROM that contains 00 or FF bytes (padding). But offcourse there is some padding in the ROM.. like there is in the original.. I dunno if data is COMPLETELY realigned, but if we find the spot that normally contains FF or 00 bytes we can maybe derive the method of encryption used here.. maybe it's some kind of incremental XOR or other bitwise magic? just guessing here..

We cannot give up on this! Either one way or another! .. maybe we can put it the other way around and try to get the DFv2 roms working on a regular flashcart + passme/flashme..

[brakken]

If I had a Neocrap I'd dump it's code in a heartbeat.

Screw getting the DF dumps to work get the GST dumps to work!

Too bad DF joined the Neocrap team otherwise I think all dumps would be working, but I can't blame the guy as money controls everyone!

[fRUiTDEV]

Originally posted by brakken
If I had a Neocrap I'd dump it's code in a heartbeat.

Screw getting the DF dumps to work get the GST dumps to work!
Ah well.. it's a start to know how to patch the ROMs :-)

Too bad DF joined the Neocrap team otherwise I think all dumps would be working, but I can't blame the guy as money controls everyone!
Yep.. where is the so-called "scene" @ these days? *yawns*

[cory149]

I'm getting more interested in the CPLD code that's contained on the NeoKey. Do you honestly believe they would use a "standard" debugging jtag/cpld in their production version wrather than a preprogrammed, one time programable/protected chip? Not doing so would just invite other flash companies not to mention the people they new they would be ticking off, to come out with neoclones. (although I expect neoclones, it wont happen as fast as if they left their hardware wide open)

Why not just learn how the passme jtag code works and make your own "GSTkey" once more is figured out about the gst roms?

I'm assuming as well that any inroads to getting the DF or GST dumps working on the hardware have been blocked, if you look onto forums where DarkFader was posting with regards to the encryption and getting the dumps playable on hardware, alot of his posts now say <DELETED> in the middle of huge threads. The only info I can find that would spark such a thing is the accusation that DF leaked hyperds, and as you can see by their page http://www.hyperds.com/ the reaction they took to it.

Act 2 "scene" 1 - possible title "preproduction of the 'realscene'" :D good name for a site www.dsrealscene.com :rolleyes:

[brakken]

"I beg to dream and differ from the hollow lies
This is the dawning of the rest of our lives
On holiday

Hear the drum pounding out of time
Another protestor has crossed the line (Hey!)
To find, the money's on the other side"

[cory149]

:(

[cory149]

Some new enlightenment has come to me since my old theories have not netted me any results, and I decided it was better to research and ask than flounder in baseless knowledge.

It appears that the DS cart slot is accessed with registers- by passing offsets and lengths to these registers the data is then accessed in that method.

There appear to be a total of 32 bits to the cart registers (from documents on the non nintendo sourced info at the DS wiki site http://www.auia.net/ds/ )

It was suggested to me that calls to these registers could be possibly modified in the arm binaries to make mem copies from the gba slot address space instead... with the unencrypted dumps available I suspect a patch program will be made eventually to do such a thing.

[fRUiTDEV]

Cory, if you are able to spot the locations where the DS cart is being accessed (I couldn't by looking at the diassembly listing of non-GST roms..) I will be more then happy to write the patcher :)

[cory149]

all I have are the cart IO from the NDS tech wiki... http://www.bottledlight.com/ds/index.php/Hardware/CardRegisters

I will attempt to isolate with dsemu 0.4.1, but I still have not figured out how to tell when the disasm is accurate... extracting the arm 7/9 bins with ndstool seems to give a bit smaller chunk to wade through with ida though.

although, disasm the smt or moster team dumper might provide all the cart commands that need to be patched...