Replies: 10 comments
-
Did you try disabling the dead code removal? |
Beta Was this translation helpful? Give feedback.
-
Looking at how ia.sinc is implemented I think ghidra wants you to override function pointer signature for the |
Beta Was this translation helpful? Give feedback.
-
Ok sorry for late answer, "eliminate unreachable code" is already disabled. @xyzz I'm not sure to understand, it does not accept code to be a function pointer, and I don't see how to define a function pointer with __regcall anyway. |
Beta Was this translation helpful? Give feedback.
-
Yeah, I have to agree. There doesn't seem to be any way to apply a function pointer type to the You can only apply function prototypes from the Data Type Manager, but defining function types there is quite limited:
Custom calling conventions are basically required to properly instruct Ghidra about things like DOS's I was able to get around the second issue by modifying the slaspecs, but then when applying the function type, Ghidra just gets upset about the type and throws a |
Beta Was this translation helpful? Give feedback.
-
Is there at least a way to tie a register to the swi/svc instruction manually so that it isn't completely ignored? |
Beta Was this translation helpful? Give feedback.
-
Ghidra v9.1 support system calls ("Created new overriding reference types, which improve and extend the ability to override calls, jumps, and callothers") and added syscall-related exercises to Advanced class. For this reason I think the issue can be close. |
Beta Was this translation helpful? Give feedback.
-
I'm not seeing how this functionality can be used on a swi/svc instruction. |
Beta Was this translation helpful? Give feedback.
-
Maybe I don't understand your question. |
Beta Was this translation helpful? Give feedback.
-
Thanks, that is working. There's only one oddity, it always adds the svc number to the function call even though it isn't part of the signature. |
Beta Was this translation helpful? Give feedback.
-
I don't think it is working for 16bit like 8086 INTs. (like DOS INT) With Guidra 9.1, I've followed the tutorial, I can't apply the "syscall" calling convention as there is no such thing, and I don't really know where to do the reference. All I get from this code for example: e000:a66d b4 00 MOV AH,KEY_PRESS_CHECK
e000:a66f cd 11 INT INT_KEY
e000:a671 c3 RET (in this OS, there are multiples INTs used for various functions, and AH is the function number from that INT called) Is this warning:
And this error in the decompiler window:
What is the way to do here? |
Beta Was this translation helpful? Give feedback.
-
I'm currently reversing an OS based on 8086/80186 that use it's own syscall convention. I have all the information about them as it is documented, and it would be nice if there where a way to explain to ghidra how they are working.
Basically, it work a bit like DOS do, there are some
INT
which are dedicated to some functions, and it use registers as parameter.I'm quite sure that Ghidra have such facility, to automatically document syscall, and take them correctly in the decompiler (instead of using the pseudo function "swi")
Let's take an example, this function is calling one of the syscall:
The function is decompiled into:
Which is almost useless as, the
flags
parameter is lost, and theswi
construction is somewhat incorrect and some crucial values in registers (hereAH
which store which function to actually call) is also lostIs there is a way to tell Ghidra more about that?
Is that is only possible for disassembly by using some script?
Is there is a way for the decompiled code to explain Ghidra that this is really a syscall and so display properly something about?
In that case I can ignore the function as I know what it is doing, but in some cases the syscall was inlined in another function call, and Ghidra get somewhat confused by it.
Beta Was this translation helpful? Give feedback.
All reactions