Core Wars 8086 safe challenge (Safe uses addition on a memory address)

Question

I'm doing a safes competition and I got this safe:

start:
add     ds:0DEDh, ax
xor     cx, cx
loop    start

From my understanding, cx will be 0 at the end of the loop and will change to FFFF at the next iteration. I also know the 0xCCh is an illegal instruction that will stop the program. how can I crack this safe?

**edit: the goal here is to stop this infinite loop. the loop has no stopping term and I need to somehow make it stop using reverse engineering. for example: this is a simple safe

safe:
  mov     ax, ds:4D2h
  cmp     ax, 1000h
  jl      safe 

this is its key, written using reverse engineering:

mov bx, 1000h
mov [4D2h], bx    
l:
    jmp l

---

This simulation of a safe and key is done inside the Core Wars 8086 engine. The rules are as follows where both safe and key are survivors in the war:

The survivors cannot place a load on fixed addresses, because the game engine loads them every turn to a random address. The programs that are generated must be COM and not EXEs and contain only 8086 instructions.

Each survivor receives a set of its own complete registers (registers), which is not accessible to the other survivors. In addition, each survivor has a "personal" stack of 2048 bytes, which is also inaccessible to the other survivors.

Before running the first round of the game, the game engine initializes all the bytes in the arena to the value 0CCh (note: this byte value is an "unsupported" instruction - details below). The engine then loads each survivor to a random location in the arena memory, ie - copies the contents of the survivor file exactly as it is. The distance between two survivors, as well as the distance between the survivor and the edge of the arena, is guaranteed to be at least 1024 bytes. The code for each survivor has a maximum of 512 bytes.

Before the first round, the game engine initializes the registers (of each survivor) to the following values:

• BX, CX, DX, SI, DI, BP - Reset.
• Flags - Reset.
• AX, IP - The position of the initial survivor, the random offset in the arena to which the survivor is loaded by the game engine.
• CS, DS - The segment of the arena common to all survivors.
• ES - A segment (segment) for the memory shared by survivors of the same group (see Advanced Techniques ).
• SS - Beginning section of the personal stack of the survivor.
• SP - Offset The start of the personal stack of the survivor.

At this point the game begins in rounds, with each round running the game engine running the next instruction of each survivor, until the end of the game: after 200,000 rounds, or when a single survivor remains in the arena. The order in which the survivors will play in each round is determined at the beginning of the game at random, and does not change during it.

A survivor is disqualified in the following cases:

• Running an illegal instruction (example: byte 060h that does not translate into any assembly instruction).
• Running an "unsupported" instruction by the game engine (example: "INT 021h"). The game engine prevents running instructions that try to initiate direct communication with the operating system or computer hardware. Attempt to access memory that is not within the realm of the arena, and not within the realm of the "personal" stack of the survivor.
• Attacking other survivors is done by writing information about their code in the arena memory (in order to get them to perform one of the above three actions), and consequently to disqualify them. Earlier, therefore, one has to find where they are hiding :)

Answer 1

Although AX has a random value, it does have meaning. That meaning is:

• AX, IP - The position of the initial survivor, the random offset in the arena to which the survivor is loaded by the game engine.

AX=IP which is the instruction pointer where the safe was loaded in memory. All we have to do is update the first instruction in the loop with something that will force the safe to exit (die). That can be done by writing a byte value of 0x60¹ to that memory address according to the documentation. Since the safe's loop is also the start of the program we just have to retrieve safe's AX value and use it to overwrite that memory address.

Getting safe's AX would have been trivial if they had just written it to memory address 0x0DED but they kept adding AX to the previous WORD (16-bit value) in memory. This means that in order to figure out what safe's AX value is we need to read it twice and subtract the first value read from the second value read. We also have to do the 2 reads in such a way that we know safe has updated it exactly once between our reads. The rules of the Core Ware engine say:

At this point the game begins in rounds, with each round running the game engine running the next instruction of each survivor, until the end of the game: after 200,000 rounds, or when a single survivor remains in the arena. The order in which the survivors will play in each round is determined at the beginning of the game at random, and does not change during it.

That means every round one instruction is executed by the safe and the key. Since the safe's loop is 3 instructions:

start:
    add     ds:0DEDh, ax ; Instruction 1
    xor     cx, cx       ; Instruction 2
    loop    start        ; Instruction 3

We are guaranteed to read 2 different values at [0x0DED] every 4 instructions. Now that we know this it becomes relatively easy. We can simplify the assembly code by realizing that secondreadAX - firstreadAX is the same as (-firstreadAX) + secondreadAX. With that in mind a solution that does 2 reads four instructions apart and updates the start of safe's code (and the start of its loop) with 0x60 could look like (in NASM syntax):

; Assemble with:
;     nasm -f bin key.asm -o key

start:
    mov bx, [0x0DED] ; Get the WORD from [0x0DED]
    neg bx           ; Negate it. BX=(-firstreadAX)
    nop              ; Need to wait at least one more instruction (3 total)
                     ;     before trying to read 0x0DED again
    add bx, [0x0DED] ; Add the current WORD value at [0x0DED] with BX
                     ;     safeAX = -BX+[0x0DED] = [0x0DED]-BX
                     ;  or safeAX=(-firstreadAX)+secondreadAX = secondreadAX-firstreadAX
    mov byte [bx], 0x60
                     ; Overwrite the first instruction of safe with 0x60
                     ;     to terminate the safe.
    jmp $            ; Infinite loop

In TASM/MASM(v6.00+)/JWASM the code would look like:

.model tiny
.code

start:
    mov bx,[ds:0DEDh]; Get the WORD from [0DEDh]
    neg bx           ; Negate it. BX=(-firstreadAX)
    nop              ; Need to wait at least one more instruction (3 total)
                     ;     before trying to read 0DEDh again
    add bx,[ds:0DEDh]; Add the current WORD value at [0DEDh] with BX
                     ;     safeAX=-BX+[0DEDh]=[0DEDh]-BX
                     ;  or safeAX=(-firstreadAX)+secondreadAX = secondreadAX-firstreadAX
    mov byte ptr [bx], 060h
                     ; Overwrite the first instruction of safe with 060h
                     ;     to terminate the safe.
    jmp $            ; Infinite loop

END

---

Footnotes

• ¹Any opcode not supported by an 8086 will terminate a survivor and this includes 0x60, 0x66, 0x67 among others. Valid 8086 single byte opcodes like 0xcc (INT3), 0xce (INTO) and 0xf1 (INT1) will also exit because they are unsupported traps in the Core Wars engine. Calling software interrupts that are unsupported by the Core Wars engine (like DOS INT 21h) will also cause a survivor to fail.

Answer 2

the goal here is to stop this infinite loop. the loop has no stopping term and I need to somehow make it stop using reverse engineering

It's not too clear what you can and can't do. Following is a solution that only requires you to change a single byte.

Going from xor cx, cx to the harmless mov cx, cx will no longer reset the loop counter and thus the loop will end some time later (depending on the initial value of CX that we do not know).
The opcode for mov cx, cx is 89h. We don't need to change the modr/m byte because its value is the same for both instructions.

mov byte [cs:start+4], 89h

It could be useful to verify that the assembler did not include the otherwise redundant DS: segment override prefix because if that's the case you would have to write mov byte [cs:start+5], 89h.