Page 1 of 1

Auditing your own code.

Posted: Thu Jan 09, 2020 2:16 pm
by add A, $100
Say you are done, assets have completed the game works and you're about to send it off.

What steps should you take to make sure no extra and unwanted code is getting your binary and related files?

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 4:24 pm
by Dwedit
Generally not a problem with your own assembly code, since you had to make everything. You can read through the listing file if you need to see if anything is out of place.

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 6:04 pm
by Garth
If your assembler's .lst (list) file output includes an alphabetized list of all the labels and how many times each label is referenced, you can see which ones never got used, and especially if they're not just local branch labels, remove (or comment-out) the particular routines.

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 6:11 pm
by Punch
I'd say keep it as is unless you're trying to make a square binary fit into a round ROM. Who knows what edge case/bug can be triggered by having some routines relocated, but that would otherwise show no symptoms and allow the game to run as intended... that always happens to me :lol:

If that's needed, maybe use an emulator that can record an usage map of data in the ROM? I'm not sure if such a thing exists for the NES but that would be my first choice to solve this, save for the assembler output listing label occurrences like mentioned.

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 6:46 pm
by tepples
It's not just fitting a square binary into a round ROM. It's making sure to declare to the age rating organization everything that's in a ROM, especially after a controversy related to Grand Theft Auto: San Andreas.

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 6:46 pm
by add A, $100
The reason that I bring it up is I don't want any malicious code getting in, when it comes to compile time.

Re: Auditing your own code.

Posted: Thu Jan 09, 2020 9:10 pm
by JRoatch
TLDR; Don't worry about malicious code sneaking in a NES project. If it can, you may have bigger issues to deal with.

To figure that out you'll have to define what "malicious code" is, and theorize how it might "sneak in".

I'm amusing a we're talking about 6502 code compiled and assembled to run on a NES via physical cart or on a virtual machine/emulator via a ROM file.

In my understanding, malicious code assumes an adversary who is not yourself. In a physical NES context the only truly malicious code I can possibly conceive of is maybe code that issues erase commands to it's own flash chip, but there would be absolutely no reason any adversary would want to sneak in such code (because it profits them not).

In a virtual machine context the issue more likely may lie with the emulator itself rather than the output of your compiler. But as you are providing the input of the emulator yourself there's no issue there.

That then leave the compiler/assembler. There's a paper titled "Fully Countering Trusting Trust ..." which addresses this issue, but even without that you can verify the resulting compiled ROM with other tools that you do trust to not expose a flaw with itself when reading the compiled ROM. Anything that doesn't execute (or do a equivalent to a "eval(rom_data)") will be safe, like a hex editor.

Or you can just rest assure that the compiler/assembler for a NES executable is not even compiling code for your computer.

Re: Auditing your own code.

Posted: Fri Jan 10, 2020 2:51 am
by nocash
I have some doubts that we are talking about the "binary and related files" of a NES ROM image here... might be as well another generic spam post?
On the other hand, an infected NES game would probably also display spam messages about cruddy 3V bootleg carts █RX SPAM█ instead of self-erasing its own FLASH memory ; )

EDIT: I did not write "my mom", that is... apparently some adult-filter, or anti-spam replacement in nesdev?

Re: Auditing your own code.

Posted: Fri Jan 10, 2020 8:57 am
by add A, $100
Thanks for the replies I'm gearing up to get going on my first project!

Re: Auditing your own code.

Posted: Sun Jan 12, 2020 8:27 pm
by tepples
Discussion of the spam that was deleted from this topic continues in another topic.