Why does the Gameboy Advance serial encryption include the destination byte address? The Gameboy Advance encrypts data sent over its serial port. It assembles a random number to seed a linear congruential generator. Then, it xors this PRN, the data, a symmetric key, and the byte offset from the file.

Is there a rationale for this? The receiver must know the byte address, because it needed to know how many times to iterate the LCG.

(See here for a description of the algorithm.)

I'm trying to determine whether the algorithm is a stream cipher or some version of a block cipher in CTR mode.
Quoting the linked source:


 if normal_mode    then c=C387h:x=C37Bh:k=43202F2Fh
 if multiplay_mode then c=FFF8h:x=A517h:k=6465646Fh
 m=dword(pp,cc,cc,cc):f=dword(hh,rr,rr,rr)
 for ptr=000000C0h to (file_size-4) step 4
   c=c xor data[ptr]:for i=1 to 32:c=c shr 1:if carry then c=c xor x:next
   m=(6F646573h*m)+1
   send_32_or_2x16 (data[ptr] xor (-2000000h-ptr) xor m xor k)
 next
c=c xor f:for i=1 to 32:c=c shr 1:if carry then c=c xor x:next
wait_all_units_ready_for_checksum:send_32_or_1x16 (c)

 pp    palette_data
 cc    random client_data[1..3] from slave 1-3, FFh if slave not exists
 hh    handshake_data, 11h+client_data[1]+client_data[2]+client_data[3]



I read the question as asking the role of xor (-2000000h-ptr).

It ads a small layer of security by obscurity, but does not strengthen the algorithm from a cryptographic standpoint, since a passive eavesdropper can know ptr by merely counting the octets exchanged.

The algorithm is a stream cipher for encryption (with the keystream obtained as the XOR of a Linear Congruential Generator m, the aforementioned (-2000000h-ptr), and key k); and a MAC for integrity (using a Cyclic Redundancy Check c with feedback polynomial defined by x). The whole thing is more security by obscurity than real crypto.

Update: The ptr term can not be naturally considered as the counter of the CTR mode of operation. For this we would need chunks of the keystream to be expressable as a function of key and counter, without other internal state evolving sequentially. Here we have other such internal state m. Otherwise said, it is easy to convert a cipher operating in CTR mode for direct access, when here the iterated LCG makes that uneasy. I see no natural way to consider this as a block cipher in any mode.

On the other hand, if we really wanted that, it is possible to express the state of the LCG m as a function F of the current value of ptr and the initial m0=dword(pp,cc,cc,cc), and then the keystream becomes (-2000000h-ptr) xor F(ptr,m0) xor k, or $E_{(\mathtt{m_0},\mathtt{k})}(\mathtt{ptr})$, and we have a CTR mode with a block cipher $E$, having extremely weak diffusion of its plaintext input. That would be grossly inefficient if we implemented F iteratively, but there are ways around.