You provide little information on what you're trying to do (or why a copy of the EXE won't do), but I'm inferring that you'd like to patch the game in-memory and then run it?

If so, a good start might be DOS function 4Bh/AL=1 (load but do not execute).

If you know the byte sequence to be patched, open the EXE in a hex editor of your choice, do the job and save as a copy.

Check out Binary diff/patch utilities
http://www.daemonology.net/bsdiff/

VileRancour wrote:

You provide little information on what you're trying to do (or why a copy of the EXE won't do), but I'm inferring that you'd like to patch the game in-memory and then run it?

If so, a good start might be DOS function 4Bh/AL=1 (load but do not execute).

My bad, I wasn't too clear about what I wanted, but yes I want to patch the game in-memory.

ph4nt0m wrote:

If you know the byte sequence to be patched, open the EXE in a hex editor of your choice, do the job and save as a copy.

Forgot to mention that the executable is compressed, the byte sequence cannot be patched. I searched all files for it, I can only find it in memory. Also I think the file loads a couple of others files too. In-memory patching was what I was looking for.

kjliew wrote:

Check out Binary diff/patch utilities http://www.daemonology.net/bsdiff/

Thank you, I will take a look.

Akuma wrote:

Forgot to mention that the executable is compressed, the byte sequence cannot be patched. I searched all files for it, I can only find it in memory. Also I think the file loads a couple of others files too. In-memory patching was what I was looking for.

I know what you mean. You have at least two ways to do it.
-write a TSR in ASM that captures some INT used by the executable you want to patch
-or capture INT and use the functions "Modify Allocated Memory Block" (INT 21h/4Ah) and "EXEC/Load and Execute Program" (INT 21h/4Bh).

Not long ago I wrote a couple of loaders to crack two games. The posts are in spanish, but I think the source code in ASM could be useful.

http://www.vlan7.org/2019/02/ms-dos-cracking- … n-cargador.html
http://www.vlan7.org/2019/04/haciendo-un-carg … oader-para.html

Happy reversing.

That is extremely helpful, thank you sir.

What I got so far writing my first ASM program, is a simple 'Hello world'.
1. I need to figure out how to patch in-memory
2. When to patch, the executable needs to decompress itself first, otherwise whats the point.
3. I would probably have to wait for the OEP, then patch it, if it doesnt decompress and loads something else too.

1.MODEL TINY
2.DATA
3    msg db "Hello, world!$",0dh     ; [var] [declare bytes] "message$", no. bytes in hex
4.CODE
5    org 100h                                ; required by com file
6START:
7    mov ah, 09                            ; int21h: function print text
8    lea dx, msg                           ; refer to msg to print
9    int 21h
10
11    mov ax, 4c00h                      ; return to dos
12    int 21h
13END START

I got it to produce a nice small com file with TASM.

1C:\>DEL TEST.MAP
2 
3C:\>DEL TEST.OBJ
4 
5C:\>DEL TEST.COM
6 
7C:\>TASM\BIN\TASM.EXE TEST.ASM TEST.OBJ
8Turbo Assembler  Version 4.1  Copyright (c) 1988, 1996 Borland International
9 
10Assembling file:   TEST.ASM
11Error messages:    None
12Warning messages:  None
13Passes:            1
14Remaining memory:  466k
15 
16 
17C:\>TASM\BIN\TLINK.EXE /t TEST.OBJ
18Turbo Link  Version 7.1.30.1. Copyright (c) 1987, 1996 Borland International
19 
20C:\>test
21Hello, world!
22C:\>
23 

A generic approach for in-memory patching is, if you tell DOS to load-but-do-not-execute the file, it is in memory and you get the segment address of the program's PSP; from there you can write to whatever locations you want within the program code. Of course, it's a good idea to test your planned patch first by using something like the DOSBox debugger to directly modify the routine in memory.

A compressed EXE is a whole different ballpark however. You might want to use some analysis tools to find out more (identify the packing scheme and perhaps find the original entry point). Ben Castricum's UNP may be a good place to start, along with its trace command "t".

I haven't tackled this before, but if I were to try writing such a loader, my approach might be to patch the unpacking code in-memory, so that once it's done unpacking (and is ready to jump to the OEP) it returns control to my loader. Then a second routine would patch the already-unpacked code in RAM with the required changes and make the jump.

Not sure if this is the best kind of project to tackle when at the hello-world level, but I did worse when I had less, so good luck. 😁

A common method with patch TSRs/loaders is to set up an interrupt handler and watch for a particular function that is called after the target program's code is decrypted and/or decompressed, then modify memory relative to the interrupt's return address that was pushed on the stack. For example, programs often call INT 21h/30h to get the DOS version as one of the first things they do, but that's not necessarily the ideal function to watch for. It's a good idea to check the memory you intend to modify to see if it contains expected values, which ensures you're patching the right thing and also not performing the patch more than once.

yeah better to hook an interrupt vector, if the app was written in C you know its going to do a dos version check or anything is garunteed to do a memory realloc (0x4A). you can hook that and patch what you need to patch.

VileRancour wrote:

A generic approach for in-memory patching is, if you tell DOS to load-but-do-not-execute the file, it is in memory and you get t […]
Show full quote

A generic approach for in-memory patching is, if you tell DOS to load-but-do-not-execute the file, it is in memory and you get the segment address of the program's PSP; from there you can write to whatever locations you want within the program code. Of course, it's a good idea to test your planned patch first by using something like the DOSBox debugger to directly modify the routine in memory.

A compressed EXE is a whole different ballpark however. You might want to use some analysis tools to find out more (identify the packing scheme and perhaps find the original entry point). Ben Castricum's UNP may be a good place to start, along with its trace command "t".

I haven't tackled this before, but if I were to try writing such a loader, my approach might be to patch the unpacking code in-memory, so that once it's done unpacking (and is ready to jump to the OEP) it returns control to my loader. Then a second routine would patch the already-unpacked code in RAM with the required changes and make the jump.

Not sure if this is the best kind of project to tackle when at the hello-world level, but I did worse when I had less, so good luck. 😁

Unpacking has never been a real problem for me, although there are some wonderful exceptions that still haunt me to this day.
(The INC loader from the Operation Wolf release iirc, thats a real nasty one)..ermm back to the topic at hand.

I plan on doing the following:
1. Write hello world
2. Write a patch for hello world, to: Hello patch!, that would hopefully cover the basics.
(debugging with dosbox debugger)
3. Deal with the unpacking, find the oep.
4. Write the patch, test and verify it.
5. Praise and glory!

I will take that luck sir!

ripsaw8080 wrote:

A common method with patch TSRs/loaders is to set up an interrupt handler and watch for a particular function that is called after the target program's code is decrypted and/or decompressed, then modify memory relative to the interrupt's return address that was pushed on the stack. For example, programs often call INT 21h/30h to get the DOS version as one of the first things they do, but that's not necessarily the ideal function to watch for. It's a good idea to check the memory you intend to modify to see if it contains expected values, which ensures you're patching the right thing and also not performing the patch more than once.

I read through some code today from 'pantercat', they hooked into INT10. I think it was something like mov ax,3510h or something.
This is going to be hard on my brain =). Yes, one iteration, that's a good one. Noted.

BloodyCactus wrote:

yeah better to hook an interrupt vector, if the app was written in C you know its going to do a dos version check or anything is garunteed to do a memory realloc (0x4A). you can hook that and patch what you need to patch.

Thank you, although most of this is 'hocus pocus' to me now. I'll get it to work eventually. I always do.😁

I see that there are a lot of different ASM-compilers, I just found out that the syntax differs too.
So my question which one of them do you recommend I use and why? Thank you

• MASM
• TASM
• A86

NASM unless your compiling it on a 286 or something. TASM would be the fallback if you dont want to learn NASM.

Hmm...its kinda working, but with a couple of issues.

1. It only works on my machine in dosbox, because its patching absolute, not relative ?
2. Its not stable, if I exit the game, the OS becomes unstable, it hangs second time around ?
3. I understand 80% of what I pieced together ?

If anyone can shed some light on this, Im all ears 😁

1OVL     segment for 'code'
2        assume cs:OVL, ds:OVL
3
4org     100h                        ; output a .COM program
5
6START:
7mov     sp, 1024                 ; set stack pointer (size in bytes)
8mov     bx, 1024/16             ; set bx=bytes/16, es=mem segment
9mov     ah, 4ah                   ; change memory allocation
10int     21h                           ; commit
11
12mov     ax, 3521h               ; get OLDINT
13int     21h                            ; commit
14
15mov     OLDINT[0], bx         ; safe OLDINT to call later
16mov     OLDINT[2], es         ; ?? no idea ?? 
17
18mov     ax, 2521h                ; set NEWINT
19lea     dx, NEWINT              ; with pointer to NEWINT proc far routine
20int     21h
21
22lea     bx, EXEC_INFO         ; ?? no idea ??
23lea     dx, FILENAME           ; pointer to FILENAME
24mov     ax, 4b00h                 ; load and run FILENAME
25int     21h                             ; commit
26
27mov     ax, 4c00h                 ; ah=exit, al=return code
28int     21h                             ; commit
29
30OLDINT  dw 0,0                    ; original INT
31
32NEWINT  proc far
33pushf                                   ; safe flags
34cmp     dx, 029DAh               ; compare if INT is called with X
35jnz     EXIT                          ; yes: goto CHECK, no: goto EXIT
36
37CHECK:
38push    bp                            ; safe 'bp'
39mov     bp, sp                      ; 'bp' points to top of the stack
40push    es                            ; safe 'es'
41mov     es, [bp]                    ; copy bp to 'es'
42cmp     word ptr es:[0XXXX], 0XXXXh ; if data matches search query
43jne     RESTORE                  ; yes: goto PATCH , no: goto RESTORE
44
45PATCH:                              ; --------------- patch -------------------
46mov     byte ptr es:[0XXXX], 0XXh   ; change byte offset es:xxxx to xxxh
47                                    ; ------------- end patch -----------------
48    
49RESTORE:
50pop     es                          ; restore 'es'
51pop     bp                          ; restore 'bp'
52
53EXIT:
54popf                                ; restore flags
55jmp     dword ptr cs:[OLDINT]       ; jump to OLDINT
56
57NEWINT endp
58
59FILENAME    db "GAME.EXE",0      ; program to execute
60EXEC_INFO   db 22 DUP (0)           ; ?? no idea : 22x 00h for what ??

61
62OVL ends
63end START

Is there a way to use a fixed font for the code window ?

At a first glance, it looks like you aren't setting up the interrupt chain correctly. Keep in mind that an "INT XXh" instruction pushes the flags onto the stack, then the far return address (dword), then jumps to the interrupt handler. The handler routine normally ends with an IRET instruction, which does the reverse (pops the CS:IP then the flags, and resumes).

So to properly call the old interrupt handler, your EXIT section should emulate the INT instruction by pushing the flags (PUSHF) and the far return address (e.g. PUSH CS, then CALL a far jump to the old handler, which pushes IP during the CALL). Then once the old handler returns (with an IRET), your NEWINT should also terminate with an IRET, since it also gets called with "INT XXh" and has to preserve the expected state. This also means there's no need for the existing PUSHF/POPF pair.

This might be some relevant reading material: https://web.archive.org/web/20080222000741/ht … abs/roehrl.html. There may be other issues, but I'd start with that.

(Edit:) also, your EXEC_INFO structure should contain a parameter block as described here: http://faydoc.tripod.com/structures/15/1590.htm - it's probably a good idea to actually set up the values. 😉 More info here: http://www.ctyme.com/intr/rb-2939.htm

you cant do a 4c exit whilst trapping int21, you need to release your int21 hook back to its original values before you exit.
your execinfo needs to be valid with fcb/psp pointers, cli, etc

I had some time on my hands, so I started coding again:
So I wrote a filepatcher 😁 (in 'nasm' as suggested)

How can I make this better ?

1[bits 16]                           ;16 bit code generation
2[org 0x0100]                        ;com-file = start address 0x100
3[section .text]                     ;code section
4
5start:
6jmp         begin
7
8%macro printf 1
9mov         dx,%1                   ;select message set in parameter %1
10mov         ah,09h                  ;select print function
11int         21h                     ;commit
12%endmacro
13
14;http://spike.scu.edu.au/~barry/interrupts.html
15;open,close,seek,write
16%macro patch 4
17mov         ax,04200h               ;select seek file, pos: start of file
18mov         bx,[handle]             ;bx = file handle
19mov         cx,%1                   ;cx = segment
20mov         dx,%2                   ;dx = offset
21int         21h                     ;commit
22jc          error                   ;if carry flag set jump to error
23mov         ah,40h                  ;select write file
24mov         bx,[handle]             ;bx = file handle
25mov         cx,%3                   ;cx = no. bytes to write
26mov         dx,%4                   ;ds:dx -> data to write
27int         21h                     ;commit
28jc          error                   ;if carry flag set jump to error
29%endmacro
30
31;function: open file
32fopen:
33mov         dx,filename             ;load filename into dx
34mov         ax,03D02h               ;select open file
35int         21h                     ;commit
36jc          error                   ;if carry flag set jump to error
37mov         [handle],ax             ;store file handle
38ret                                 ;return to caller
39
40; function: close file
41fclose:
42mov         ax,03E00h               ;select close file
43int         21h                     ;commit
44jc          error                   ;if carry flag set jump to error
45ret                                 ;return to caller
46
47error:
48printf      error1
49jmp         exit                    ;jump to exit
50
51begin:
52printf      title                   ;print message
53call        fopen                   ;open file to be patched
54patch       p1seg,p1ofs,p1len,p1dat
55patch       p2seg,p2ofs,p2len,p2dat
56patch       p3seg,p3ofs,p3len,p3dat
57call        fclose                  ;close file
58printf      success                 ;print message
59
60exit:

61mov         ax,04C00h               ;select return to dos
62int         21h                     ;commit
63
64[section .data]
65filename    db 'filename.exe',0     ;target filename
66title       db 'Patch for program: blah blah blah',0AH,0DH,'$'
67error1      db 'Failure',0AH,0DH,'$'
68success     db 'Success',0AH,0DH,'$'
69handle      dw 0
70
71;patch1
72p1seg       equ 00000h              ;segment: most significant byte
73p1ofs       equ 00000h              ;offset: least significant byte
74p1dat       db  0x90,0x90,0         ;string
75p1len       equ $-p1dat             ;length
76
77p2seg       equ 00000h              ;segment: most significant byte
78p2ofs       equ 00100h              ;offset: least significant byte
79p2dat       db  0x90,0x90,0         ;string
80p2len       equ $-p2dat             ;length
81
82p3seg       equ 00000h              ;segment: most significant byte
83p3ofs       equ 00200h              ;offset: least significant byte
84p3dat       db  0x90,0x90,0         ;string
85p3len       equ $-p3dat             ;length

BTW:is there a way to use a fixed size font for the code window ?

The file patcher was a good stepping stone, but I'm still stuck with the loader.
Now I switched to NASM as BloodyCactus suggested, but I'm running into some conversion trouble.

So I adapted the code as best I knew how according to this: http://left404.com/2011/01/04/converting-x86- … masm-to-nasm-3/ , but I can't get it to work.

Thus I grabbed one of pantercat's loaders, tried a conversion, but dosbox screams bloody murder on execution.
error: illegal read from cs:ip (continuously), obviously I messed up somewhere but I cant figure out where as
the code compiles. My best guess would be the exit: jump but this isnt jeopardy 😁

Some help would be appreciated:

1[bits 16]                           ;16 bit code generation
2[org 0x0100]                        ;com-file = start address 0x100
3[section .text]                     ;code section
4
5START:
6jmp INITCODE                        ; Codigo de inicializacion
7
8NEWINT:
9    cmp ah, 1                       ; Se ha llamado a INT 16h con la AH=1 ?
10    jnz EXIT                        ; NO: saltamos a la INT 16h del sistema
11    cmp word [0097], 0d75h          ; ¿Tenemos en [0097] los opcodes 75 0D?
12    jnz EXIT                        ; NO: saltamos a la INT 16h del sistema
13    mov word [0097], 9090h          ; escribimos los 90 90 en [0097]
14
15EXIT:
16    jmp dword [cs:OLDINT]           ; Saltamos a la INT 16h del sistema
17
18INITCODE:
19    mov sp, SIZE                    ; redefinimos la pila
20    mov bx, SIZE/16
21    mov ah, 4Ah                     ; redimensionamos bloque memoria
22    int 21h
23
24    mov dx, MSG
25    mov ah, 9                       ; Escribimos texto por pantalla
26    int 21h
27
28    xor ah, ah                      ; Esperamos pulsacion de tecla
29    int 16h
30
31    mov ax, 3516h                   ; Queremos el valor del puntero a la INT16
32    int 21h
33    mov word [OLDINT+0], bx         ; Guardamos puntero a la INT 16h
34    mov word [OLDINT+2], es         ;  (necesitaremos llamarla despues)
35
36    mov ax,2516h                    ; Sobreescribimos en el vector INT 16h
37    mov dx, NEWINT                  ; un puntero a nuestra rutina NEWINT
38    int 21h
39
40    mov bx, EXEC_INFO
41    mov dword [bx+00h], 0
42    mov dword [bx+02h], 80h         ; PSP
43    mov word  [bx+04h], cs
44    mov word  [bx+06h], 5Ch         ; FCB 0
45    mov word  [bx+08h], cs
46    mov word  [bx+0ah], 6Ch         ; FCB 1
47    mov word  [bx+0ch], cs
48
49    mov dx, FILENAME
50    mov ax, 4b00h
51    int 21h                         ; cargar y ejecutar programa
52
53    push cs
54    pop ds                          ; DS = CS
55    mov ax, 4c00h                   ; terminar
56    int 21h
57
58[section .data]
59SIZE        EQU 1024                ; este programa y su pila caben en 1 KB
60FILENAME    db "COLMENA.EXE",0      ; programa a ejecutar

61EXEC_INFO   times 22 db (0h)
62MSG         db 0dh,0ah
63            db "La Colmena CGA/EGA/Hercules/VGA-16 loader.",0dh,0ah
64            db "2019, vlan7",0dh,0ah,"$"
65OLDINT      dw 0,0                  ; Espacio para el puntero a la INT 16h

The most obvious issue is that INT 16 is not "unhooked" before the program terminates; but that would only causes a crash after termination when the program's memory block is released, leaving the INT 16 handler code likely to be overwritten by the next program executed.

A more subtle issue is that INT 21/35 is changing the value of ES, and INT 21/4B uses ES:BX as a pointer to the child program's parameter block. So, you should have a PUSH CS / POP ES or so after the ES value has been stored in memory.

Those are the issues that I notice at a glance, not necessarily the only issues.

BTW, when the subject matter is applicable to DOS programming in general and not just for DOSBox, such topics are best posted in Milliways. 😉

What about using one of those old DOS Game cheater programs that you load up before your game. Then you load the game and press a hotkey sequence and it drops to the game cheater and lets you edit memory values and then go back to the game.

Generally used for changing lives, ammo, etc, but I would think it would work for patching as well.

I think some of them might have let you save profiles.. don't remember though. I haven't used one in years.