Auditing your own code.

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
add A, $100
Posts: 3
Joined: Thu Jan 09, 2020 2:07 pm

Auditing your own code.

Post by add A, $100 » Thu Jan 09, 2020 2:16 pm

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?

User avatar
Dwedit
Posts: 4246
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Auditing your own code.

Post by Dwedit » Thu Jan 09, 2020 4:24 pm

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Garth
Posts: 152
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Auditing your own code.

Post by Garth » Thu Jan 09, 2020 6:04 pm

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.
http://WilsonMinesCo.com/ lots of 6502 resources

User avatar
Punch
Posts: 356
Joined: Sat Feb 16, 2013 11:52 am

Re: Auditing your own code.

Post by Punch » Thu Jan 09, 2020 6:11 pm

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.
This is a block of text that can be added to posts you make. There is a 255 character limit.

tepples
Posts: 21802
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Auditing your own code.

Post by tepples » Thu Jan 09, 2020 6:46 pm

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.

add A, $100
Posts: 3
Joined: Thu Jan 09, 2020 2:07 pm

Re: Auditing your own code.

Post by add A, $100 » Thu Jan 09, 2020 6:46 pm

The reason that I bring it up is I don't want any malicious code getting in, when it comes to compile time.

JRoatch
Formerly 43110
Posts: 389
Joined: Wed Feb 05, 2014 7:01 am
Location: us-east
Contact:

Re: Auditing your own code.

Post by JRoatch » Thu Jan 09, 2020 9:10 pm

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.

nocash
Posts: 1113
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Auditing your own code.

Post by nocash » Fri Jan 10, 2020 2:51 am

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 (word replaced by spam filter) 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?
Last edited by nocash on Fri Jan 10, 2020 5:43 pm, edited 1 time in total.

add A, $100
Posts: 3
Joined: Thu Jan 09, 2020 2:07 pm

Re: Auditing your own code.

Post by add A, $100 » Fri Jan 10, 2020 8:57 am

Thanks for the replies I'm gearing up to get going on my first project!

tepples
Posts: 21802
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Auditing your own code.

Post by tepples » Sun Jan 12, 2020 8:27 pm

Discussion of the spam that was deleted from this topic continues in another topic.

Post Reply