decompiling 16-bit x86 with non-standard CS

[samrussell]

I'm decompiling an unpacked version of commander keen #1 and I get this error in the decompiler:

Offset must be between 0x0 and 0x10ffef, got 0x23055660 instead!

The app has CS = 0x2305 and I think something is broken with the memory mapping

[Malvineous]

I got the same issue. Sometimes it works and sometimes not. Looking more closely, it seems that if the function has a reference to the data segment that hasn't been mapped properly then this error will happen, and you can fix it by mapping it properly.

In my case there was a word ptr[SI + 0x1234] that hadn't been mapped anywhere so I got an error the same as yours. I had to map this pointer to the data segment and set the data type to be an array of words and then the decompiler worked.

So I would suggest finding the addresses in the data segment it's complaining about and setting them to a data type instead of the default 'undefined'. If that isn't enough then also add some mappings (right-click, References, Add/Edit) and make it a memory reference to the right offset in the data segment.

[samrussell]

That makes sense, there's a bit of segment juggling at the start of the app (lz91 apogee game) so it doesn't surprise me that it might mess with heuristics, I'll try setting DS and seeing what happens

…

On Sun, 2 May 2021, 11:52 Adam Nielsen, ***@***.***> wrote: I got the same issue. Sometimes it works and sometimes not. Looking more closely, it seems that if the function has a reference to the data segment that hasn't been mapped properly then this error will happen, and you can fix it by mapping it properly. In my case there was a word ptr[SI + 0x1234] that hadn't been mapped anywhere so I got an error the same as yours. I had to map this pointer to the data segment and set the data type to be an array of words and then the decompiler worked. So I would suggest finding the addresses in the data segment it's complaining about and setting them to a data type instead of the default 'undefined'. If that isn't enough then also add some mappings (right-click, References, Add/Edit) and make it a memory reference to the right offset in the data segment. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2948 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJUP5COW5ZVMGHGVQVCEDTLUOFNANCNFSM43D7E5AA> .

[Malvineous]

I'm looking at Dangerous Dave myself and very impressed at how well Ghidra works. By far the best disassembler I've ever used.

I'm very familiar with Commander Keen (I run the Commander Keen Wiki) and the community has pretty much fully reverse engineered the game (look at all the patches they have) so unless you're doing it for the exercise that particular game series is pretty well reverse engineered.

[samrussell]

Dangerous Dave sounds awesome! Yeah the goal is for the exercise, I've been looking into decompiling techniques and this seemed like a nice target to use to test out some ideas with

…

On Sun, 2 May 2021 at 15:21, Adam Nielsen ***@***.***> wrote: I'm looking at Dangerous Dave myself and very impressed at how well Ghidra works. By far the best disassembler I've ever used. I'm very familiar with Commander Keen (I run the Commander Keen Wiki <http://keenwiki.shikadi.net>) and the community has pretty much fully reverse engineered the game (look at all the patches they have <https://keenwiki.shikadi.net/wiki/Category:Patches>) so unless you're doing it for the exercise that particular game series is pretty well reverse engineered. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2948 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJUP5TR45XGX55VDR74RDTLVGWJANCNFSM43D7E5AA> .

[ryanmkurtz]

Fixed by 0e81327