ROM Hack NDS file lock

[NsmB_PrO]

Hello,

I have got a problem!
I have made a Hack of NSMB with the nsmb editor, but I want to "lock" my ROM, so the editor cant open the ROM anymore...
Then I want to create a xDelta patch of the ROM...
If other people patch their ROM with my patch, they should not be able to open the ROM with the editor!

There are many thiefs of hacks over the internet, so I want to be sure, my HACK is "Protected"!

Thanks in advance...

NsmB_PrO

 

[twiztidsinz]

Nope.


Not even if you're that SKJmn guy.

 

[Rydian]

Not even if you're that SKJmn guy.

Just so you're aware OP, this is a reference to somebody that made another hack and then lied about the files being protected to get people to not attempt to mess with it because he knew it wasn't possible to stop it.

 

[FAST6191]

I assume you have seen some rom editors in the past offer such a feature- in reality they just add a little flag somewhere in the rom that the editor checks and the rom could not care less about. Any partway competent hacker can work around this to get the editor working again (check "protect", make change, save, uncheck protect, make same change, save, compare files and bam you have your flag position, might have to repeat a few times if the editor uses multiple "protect" points or false flags). This is also a program level protection- someone makes another editor (or uses an older version) it does not have to accept the flag and things can carry on.

Your only real option is to allow you to "prove" such a thing- lots of DS files and formats have lots of blank space buried in them that does nothing. Add NsmB_PrO to various parts of these blank spaces and anybody that half inches your work will be able to be found out. Again not ideal and easily worked around but there are few other options.

You probably could pervert the compression used or otherwise encrypt things in the rom but I sense this is going to be somewhat outside your skillset- if you had to ask how.........

Personally I say do not even bother with trying to protect it- you know you did some work, those that matter probably know you did some work and anybody that edits it might even make something better (in case you missed it the entirety of rom hacking is about making existing works better).

Edit- on second thoughts you might be able to exploit a difference between the editor assumptions and the rom proper- simply due to the way the numbers work out certain points in the file are always in the same place (the start of various sections for instance) but they are pointed at in the initial or section headers anyway*. You might be able to change this and if the editor has assumed they always will be in the same place it will then fall over. Again any competent hacker will see what you have done and work around it in ten seconds but the editor types might have a bit more trouble.

* http://llref.emutalk.net/nds_formats.htm#Generic and some of the stuff at http://llref.emutalk.net/v2/docs.php should provide a rough overview.

edit2- it will not stop someone simply lifting your data and adding it to theirs but in one of the later versions (it is all up on filetrip) crystaltile2 added a rom intro feature (adding an intro to a rom).

I should also say should someone come around these parts asking for help to bypass some protections they probably will get it.

 

[NsmB_PrO]

thank you very much

But I already know a ROM what is protected

And I know, what file I have to encrypt! But I dont know how to do encrypt it

I have only to encrypt ONE file in the WHOLE ROM! When this is done, nobody is able to change anything in the ROM! (except HEX)

But I will try to figure out how to make a ROM uneditable!

@twiztidsinz: I am much better in NSMB-Hacking than SKJmin! He has just A LOT OF TIME! I have already made cool new stuff in my and a friends hack!
For example: Walk BIHIND Tiles, Raining level, New Animated ?-Blocks, A new endcastle in the wii style!, a shy guy enemy
All this things need MUCH time to do, because not every fool can do this...
It requires a lot of knowledge in NSMB Hacking to do such stuff!

And because of this, I want to protect my Hack! Because then, not every fool can use my COOL stuff!

 

[FAST6191]

One file in the entire rom huh.

I guess this means a single level file- anyone can swap a binary/overlay out (indeed several hacks have even been distributed as such) if you are thinking that and even if you encrypt it at rom level it will likely be sitting nicely in the ram freely available to any memory dumper someone cares to load up (I have used such techniques in the past if I am too bone idle to reverse the compression).

To this end you could probably apply a simple cipher (XOR or something) to a file in question and hook into the file read command for that file to reverse it as and when it is loaded- assuming this works (roms can do checks on full binaries often enough for AP I guess so speed should not be an issue) a would be simple editor user is unlikely to be able to bypass it. Such a hack is well into full blown ASM hack territory though*.
If you just want basic protection them I stand by my earlier suggestion to make it so that the editor falls over as it encounters something it does not expect- make something that is technically at a variable position (at least according to the game code) but as it always lands in the same place the editor will probably assume it is a set location and fall over when it encounters something the changed.
We saw similar things with NARC files as they gained nameless files, extensive subdirectories and other such things- what we had reverse engineered was just part of the spec and upon encountering something it did not expect the tool would break. With the rom being coded for it though it never knew something was "wrong".

*personally I would find where it loads in memory and continuously run a check on it (include a magic stamp in your encrypted file to say it is encrypted or something)- should it encounter the encrypted file then it will pause and fire up (branch to) the XOR routine to decrypt the relevant memory section and allowing the rom to carry on running. Come to think of it you might just be able to do this as a cheat and inject it in with something like DSATM to save too much fiddling at assembly level.

Frankly though I do not see the need and again should someone come and say "I found this cool hack but it does not load in the editor" someone who knows how to hack things will probably tear your protection apart for the fun of pulling a protection apart if nothing else.

But I already know a ROM what is protected

I have seen some odd things done to roms that makes life more difficult for the would be hacker, saves have had some interesting things done to them in the past (again simple ciphers at best) and some AP also doubles up as rudimentary protection but actual protection would be new. Care to share the name of this rom?

 

[Rydian]

I'm interested as well.

 

[rastsan]

not on topic, but FAST6191 what are you sing to put the asm in? I need this for 7th dragon to fix that screen closing issue... dsatm renders the game unusable. It can't be cropped, replacing the files with nitroexplorer also doesn't work... Is also needed for a re-route...
or am I missing the obvious and not seeing something again?

 

[FAST6191]

I do not really do that much ASM changing work these days (been working out how to pull apart file formats at the ASM level) and even if I do most of it is "destructive" (replacement opcodes drummed up by hand and the like) or the odd jump somewhere for a very small routine. The screen is just another "button" so you can probably sort it with a destructive style code (NOP or otherwise bypass the interrupt or something).

As for DSATM I believe it uses fixed points for code injection these days as it "works for most games"- you might have the exception to this and have accidentally overwritten something the game needs. Try grabbing and older version and messing around with deadbeef padding- http://min.midco.net/cracker/DSATM.rar (some games wipe ram to begin with but that should be easy enough to bypass).

Equally if you are fiddling around with it and have the gear can you try reading something from the GBA slot- it is still mapped on the DS at 08000000 to 09FFFFFF . 32 megs of relatively high speed read only memory space is too good to pass up really but I have not got around to trying it out yet.

As for replacement files- if nitro explorer does not work I guess you are going manual. If I have to do such things I usually like to make the relevant files far "bigger" and then use something like NDSTS to inject things.

 

[NsmB_PrO]

Care to share the name of this rom?

New Super Mario Bros. (E)
In the locked NSMB ROM I know, the file "fat.bin" is encrypted.
If I open it with the HEX Editor, the file holds only "00 00 00...."

I know that "PRO-HACKER" will be able to "steel" my hack! But I only want, that not every NSMB Hacker gets my stuff...

 

[Tubby28]

when you fear that somebody steal elements from your hack i have a great idea "never release your hack" Ok!

 

[_Chaz_]

when you fear that somebody steal elements from your hack i have a great idea "never release your hack" Ok!

That's the WORST idea I've ever seen anyone suggest.

 

[rastsan]

@fast6191 making things bigger makes so much more sense now. But no the problem I am having is getting rid of 40 or so in file fonts - honestly there is space to spare if I can get rid of them then repoint to the disused space... now that I say it, it still sounds like I still need to learn more. sigh. back to the blasted asm book. nevermind.

 

[FAST6191]

Repoint or relink? Unlike the PSP there are no relinking tools for the DS that I know of but if you have 40 odd fonts and they are all approximately the same format (or can otherwise be substituted for one another) then the idea is very similar to the basic SDAT hacks to play other songs or indeed the old GBA space reclaiming methods- change the location and the length for the file name. You just take it one step further and use the extra space.

Also I meant to say NDSTS in the closing paragraph not DSATM (I just edited it). NDSTS simply injects files that are the same size at the relevant location- if the rom crashes after editing with that then it is very much your fault (your file level editing or reversing was not good enough). If you take it a step further and boost all the files ahead of the one you want by 200 bytes (simple addition- I even use spreadsheets to do it) and then change the file and rom lengths in the header sections you have just given yourself an extra 200 bytes and the rom should have no reason at all to complain unless somone hard coded a value (I have never seen it although frankly I have not looked).
Better yet point this file at the end of the rom (this is more of a test method rather than a production grade method), change the location to the end of the file, file length to whatever you want and overall rom length to the original + new file length (if nothing else saving hassle with an overzealous rom trimmer) and you have yourself unlimited space on a rom that does not take to being rebuilt.

@NsmB_PrO interesting. If it is all 00's then it is held elsewhere in the rom or otherwise overlayed as an intro of sorts- the nitro rom file system is not mandatory although all roms I have seen use it at least to hold their further files (there are many roms with big files holding all the files proper the rom uses- one of the Tony Hawks games, the first phoenix wright and the star wars game that took a fair few teams a while to fix for example).