0

I am working on editing an old DOS program's assembly, but I'm running into some odd issues.

I'm using IDA Pro 6.4 and a hex editor to patch. I'm code-caving the new data by removing old stuff never used.

Just changing the assembly code does nothing, in the sense that it just exits, no errors or nothing. The code properly disassembles and looks right, but it doesn't do anything. The code is 100% right as I'm basing it off another application. There is no protection as I explain below, other changes work. However anything that involves "call" or variables other than what was originally used...don't work.

Here is an example of what I'm doing:

Code presently reads a ISA card for some data. I am making it fread a file instead.

The program is compiled using Watcom 9.5 and uses Causeway extender. It uses fastcall not stdcall.

I'm starting to pull my hair out because I need to rework the logic so it does some other stuff (write to file for example).

It's odd because simple changes to the logic work as I've made many other micro changes (jnz to jz for example).

Any advise? Is there something in the file I'm missing? If you need more info, let me know.

Here is an example of a change I've tried to make (this is the NEW code):

push    ebx
push    ecx
push    edx
push    esi
push    edi
push    ebp
mov     ebp, esp
sub     esp, 4
mov eax, offset pathname
push eax
call printf_
pop     ebp
pop     edi
pop     esi
pop     edx
pop     ecx
pop     ebx
Improve this question
10
  • Can you debug your target? How do you test if your changes work?
    – Vladislav Ivanov
    Jan 10, 2017 at 7:14
  • real hard ware and dosbox. i cant understand why simple changes don't work. it seems as if its executing because if i dont have the pops in there, it crashes.
    – Thomas
    Jan 10, 2017 at 14:38
  • 1
    Have you updated the relocation table?
    – nrz
    Jan 10, 2017 at 20:42
  • 1
    Well, then I can only suggest to step through it in debugger and figure out what's going wrong with the patched code.
    – Igor Skochinsky ♦
    Jan 10, 2017 at 23:23
  • 1
    @nrz YES! Just verified it was the relocation table (fixup table). I can now finally put some effort into this. I found a tool called "lxdump" that REALLY helped me.
    – Thomas
    Jan 11, 2017 at 6:57

2 Answers 2

Reset to default
1

In case of Watcom fastcall uses eax, edx, ebx, ecx for the first 4 arguments, however your code is pushing eax and is not restoring the stack afterwards. You should probably either add another pop (e.g. pop eax) after the call or an add esp, 4, OR use the esp value you saved in ebp, i.e. mov esp, ebp.

Improve this answer
2
  • I've done that too, same result. I'll rewrite the patch and post it. I wanna figure this out so any help is MUCH appreciated.
    – Thomas
    Jan 10, 2017 at 23:03
  • Also, shouldn't the edit ATLEAST produce the printf result?
    – Thomas
    Jan 10, 2017 at 23:05
1

In the end, the issue was due to the fixup tables. I wrote custom code to read the LE structure and thanks to some documents, figured out what offsets were being fixed up.

Please note, you need to parse the Fixup Page table and then loop through checking positions. Then read the record data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.