PinoBatch: remove remaining NESisms, reported by NieDzejkob

2018-09-02T15:31:33Z

remove remaining NESisms, reported by NieDzejkob

PinoBatch: Adapted from own work at https://wiki.nesdev.com/w/index.php/Watermarking

2018-09-02T04:50:23Z

Adapted from own work at https://wiki.nesdev.com/w/index.php/Watermarking

New page

'''Watermarking''' is [[wikipedia:Digital watermarking|defined by Wikipedia]] as "the process of embedding information into a digital signal in a way that is difficult to remove."
In some cases, the developer of an unreleased Game Boy program wants to distribute copies to beta testers but still [[wikipedia:Traitor tracing|trace]] any [[wikipedia:Internet leak|leaked]] copies of the program to the tester who broke the non-disclosure agreement.
There are several ways to produce binaries that can be traced back to a particular recipient.

== Shuffling ==
One way to make each copy unique is to shuffle, or randomly rearrange, pieces of a program at compile time.

A code preprocessor can randomize the order of statically allocated variables in a program.
This causes the addresses embedded in the code to change every time the program is compiled.
It has benefits beyond watermarking: as the program is shuffled, a randomly chosen variable acts as a [[wikipedia:Buffer overflow protection|canary]] for the variable before it, and the effects of a [[wikipedia:buffer overflow|buffer overflow]] may become more apparent.

A code preprocessor can shuffle the order of subroutines or lookup tables in a program.
Watch out: A common technique on the GB is the "[[wikipedia:Inline expansion|inline]] [[wikipedia:tail call|tail call]]", in which a subroutine doesn't return but instead falls off the end into the following subroutine.
You'll need to take this into account when adding markup to control the preprocessor.

A code preprocessor can shuffle the order of instructions in a subroutine.
In a lot of cases, the order of instructions doesn't matter, such as <code>LD</code> instructions to copy the top and bottom halves of a 16-bit value between registers.
Writes to some [[Video Display|PPU registers]] act similarly: when setting up SCX, SCY, WX, and WY, it doesn't matter which is written first.
The markup for such "bundles of instructions" resembles the markup for stop bits in [[wikipedia:explicitly parallel instruction computing|explicitly parallel instruction computing]].
Adding the required markup also has a benefit beyond watermarking: thinking about what instructions affect others forces a code review, which allows a programmer to refamiliarize himself with a code base and possibly discover defects.

If your game uses an [[MBC1]] or [[MBC5]], you can shuffle the order in which banks appear in the ROM. For example, one copy might put a particular level's tile data in bank 3 and another in bank 5.
If you shuffle the data in banks 1 through 7, you can make 7! = 5040 different binaries from this alone.

Even in a game with no MBC, shuffling alone allows for more distinct binaries than the number of atoms in the known universe squared.
With the size of GB games and with modern solid archiving tools such as 7-Zip, you can save each binary that you send out to each tester and still not fill a 4 GB USB flash drive.
As long as the binary doesn't get leaked to someone with the knowledge to disassemble and reassemble a binary (as in pret's ''Pokémon'' disassemblies), computing the [[wikipedia:Hamming distance|Hamming distance]] between the leaked copy and your saved copies is likely to result in a high-confidence match to the leaker.

== Instruction encoding ==
A few instructions have multiple encodings that differ only in aspects that are not important in a particular case.
* <code>add imm</code> and <code>sub imm</code> differ in the carry
* <code>rla</code> and <code>adc a</code> differ in zero
* <code>xor a</code> and <code>sub a</code> are nigh identical
* <code>or a</code> and <code>and a</code> are nigh identical

A code preprocessor can introduce any of several NOP instructions at random points in a non-time-critical subroutine, such as <code>ld c,c</code>.
One may also add official do-(near)-nothing instructions such as <code>xor 0</code>, <code>or 0</code> <code>cp a</code>, <code>and a</code>, or a pair of <code>dec e</code> then <code>inc e</code>.
Another watermarking padding stratagem would be, before a load instruction for a register (LDA, LDX, LDY, PLA, TAX, TAY, TSX, TXA, or TYA), to introduce instructions affecting that register; the load makes irrelevant all changes to the register's contents. One should, of course, take care to ensure that such new instructions do not have undesired flag changes altering execution flow.

The addresses of MBCs' writable ports are incompletely decoded because the MBC ignores low address bits.
Each MBC1 port, for example, appears 8192 times.
A code preprocessor could randomize these address bits in any instruction that reads or writes MBC ports.
This would also serve to hinder a cracker's use of an in-emulator debugger that doesn't take mirroring into account.

== Graphics changes ==
Graphics can depend on the build:
*Choose one of several alternatives for [http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/chapter1.htm grass] and other [http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/chapter3.htm noisy tiles]
*Rearrange the order in which sets of tiles appear in the CHR ROM
*Tester's name or something derived from tester's name on the title screen. This is easy to remove, but it acts as a deterrent.
*Tester's name or something derived from tester's name on a sign in a building in the game

== Compression ==
If your program includes compressed data, you can change the interpretation of bits in the data format.
For example, in RLE tile compression, the sense of bits denoting a run of repeated pixels vs. bits denoting a run of several literal pixels can be inverted.

== External links ==
*[https://wiki.nesdev.com/w/index.php/Watermarking Watermarking on NESdev Wiki]
*[https://github.com/pinobatch/croom-nes/blob/master/tools/shuffle.py shuffle.py]: a code preprocessor that shuffles lines of code

@@ Line 36: / Line 36: @@
 A code preprocessor can introduce any of several NOP instructions at random points in a non-time-critical subroutine, such as <code>ld c,c</code>.
 One may also add official do-(near)-nothing instructions such as <code>xor 0</code>, <code>or 0</code> <code>cp a</code>, <code>and a</code>, or a pair of <code>dec e</code> then <code>inc e</code>.
-Another watermarking padding stratagem would be, before a load instruction for a register (LDA, LDX, LDY, PLA, TAX, TAY, TSX, TXA, or TYA), to introduce instructions affecting that register; the load makes irrelevant all changes to the register's contents. One should, of course, take care to ensure that such new instructions do not have undesired flag changes altering execution flow.
+Another watermarking padding stratagem would be, before a <code>ld</code> instruction for a register, to introduce instructions affecting that register; the load makes irrelevant all changes to the register's contents. One should, of course, take care to ensure that such new instructions do not have undesired flag changes altering execution flow.
 The addresses of MBCs' writable ports are incompletely decoded because the MBC ignores low address bits.
@@ Line 42: / Line 42: @@
 A code preprocessor could randomize these address bits in any instruction that reads or writes MBC ports.
 This would also serve to hinder a cracker's use of an in-emulator debugger that doesn't take mirroring into account.
 == Graphics changes ==
 Graphics can depend on the build:
 *Choose one of several alternatives for [http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/chapter1.htm grass] and other [http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/chapter3.htm noisy tiles]
-*Rearrange the order in which sets of tiles appear in the CHR ROM
+*Rearrange the order in which sets of tiles appear in the ROM, even within a bank
-*Tester's name or something derived from tester's name on the title screen. This is easy to remove, but it acts as a deterrent.
+*Tester's name or something derived from tester's name on the title screen. This is easy to remove, but it acts as a deterrent and evidence of intent.
 *Tester's name or something derived from tester's name on a sign in a building in the game

Watermarking - Revision history

PinoBatch: remove remaining NESisms, reported by NieDzejkob

PinoBatch: Adapted from own work at https://wiki.nesdev.com/w/index.php/Watermarking