Real-mode MSDOS code - switch reconstruction ? about reko HOT 16 CLOSED

Indeed, you have to prove that DS is constant before you can change the instruction from Mem[ds:bx + 0x04F9] to Mem[(ds_04F9) + bx]. The Scanner uses the ProcedureState class to keep a track of what registers are constant on entry to functions (a weak version of Value Set Analysis (VSA) that I implemented before I knew what VSA was). If ProcedureState[ds] is a constant (i.e. not invalid), then that fact should be taken advantage of.

Note that if the instruction had been mov bl,[cs:bx + 0x4F9], reko's scanner should do the right thing, since CS is obviously known.

If reko can't prove that DS is known, it can't resolve the switch. It wouldn't be very hard to add a dictionary, called AssumeRegisterValues or something, to the UserProcedure class. Users could add the key-value pair "DS = 0x1234" here. Then, when the scanner scans the procedure containing the switch statement, it would consult the KnownRegisterValues and override anything in the ProcedureState. Here we are using the user as an oracle; obviously if the user is mistaken, then reko will be led astray.

Would you like me to add this AssumeRegisterValues capability, given the lack of a full-blown VSA at the moment? It's more expedient, and kind of hacky, but it could prove to be quite useful. One should be able to add AssumeRegisterValues at any instruction address, of course.

from reko.

I went ahead and implemented this feature for procedures. To set the assumed register values of a procedure, right-click on it in the project browser and select "Register values..." These will be saved in the project file.

from reko.

Great 😄

I'll test it out as soon as I'm able and report back here

from reko.

To allow setting the assumed register values on an instruction by instruction basis, we need to implement #30. But the data segment doesn't change often so you should be OK.

from reko.

1. I'm converting IDA Pro .idc script. Can you implement "the assumed register values on an instruction by instruction basis" inside project xml file? So we will not need to wait for #30.
2. Maybe I'm doing something wrong: I defined global variables. I can see their names and sizes. I assumed ds for one function. But C output still contain Mem[SEGMENTREGISTER:OFFSET].

from reko.

1. I can look into this on Tuesday when I will have access to a computer again.
2. If a Reko pass fails, due to exceptions, it will cause some or all segmented accesses to remain untranslated. Are you seeing any errors when you decompile your binary?

from reko.

Thanks.
Yes, there are errors. It might be reason.
(no address or decompailer source file/line so cannot understand the root cause):
Warning,0800:24E6,Procedure sub_1279A previously had a return address of 0 bytes on the stack, but now seems to have a return address of 2 bytes on the stack.
Warning,0800:7551,Procedure setmemalloc2 previously had a return address of 2 bytes on the stack, but now seems to have a return address of 0 bytes on the stack.
Warning,0800:754F,Procedure setmemalloc1 previously had a return address of 2 bytes on the stack, but now seems to have a return address of 0 bytes on the stack.
Error,,An internal error occurred. Haven't handled this case yet.
Error,,Error when reconstructing types. Not implemented: edx_eax_13 % edi_21

from reko.

It's the last two errors that cause subissue 2 above. Is there any chance you could provide me with the binary? You should have gotten some context for the errors, that is a bug in itself.

from reko.

binary is here https://cloud.mail.ru/public/2r7E/vja27S4je

from reko.

I can see also not all functions are decompiled. It is because of errors? So errors are critical and decompilation is not possible?

from reko.

If reko is missing functions, it's because it cannot prove that those functions are reached. It's unlikely that directly called functions (e.g call 0123:1235) will not be decompiled. However, indirectly called functions are easily missed (e.g. call far ptr es:[bx+0x10]). In such cases, reko lets you (the user) specifically mark a location as being the start of a procedure, using the Mark as Procedure menu item, in the memory viewer.

from reko.

1. This helps. And the function is decoded. But when I do save+close+reopen the project looks like this Procedure mark is not stored to project file.
2. Do I really need manually specify the Procedure entry point? Because I already added all procedure names and address in the project file. Maybe decompiler should reuse this info?

       <procedure name="moduleread">
        <characteristics />
        <address>0800:0000</address>
      </procedure>

from reko.

Shall we move this over to https://gitter.im/uxmal/reko ? I'd be willing to help out troubleshooting, but I don't want to spam this issue entry, which is about assumed register values (I'm working on that right now btw)

from reko.

@xor2003: commit 5f15a4c on the branch user-register-statements allows you to specify register values at any address of the program. You will have to edit the dcproj file directly until there is a user interface for it. To specify register values, add the following to the dcproj file:

<project>
  <input>
    <!-- stuff elided for clarity -->
    <user>
      <registerValues>
        <assume addr="0C00:0234" reg="ds" value="0D0A" />
      </registerValues>
    </user>
  </input>
</project>

Reko implements this by injecting the following statement "before" the actual instruction at 0C00:0234:

ds = 0x0D0A

Please let me know how this works for you, and if you have any other ideas or suggestions for this feature.

from reko.

Thank you. It should be ok. I will try to test it. I need to build the branch, right? Cannot guaranty it will be soon

from reko.

I've merged the changes into the master branch; you won't need to build the branch. Give me a holler if you need help building and such.

from reko.