You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some x86 32-bit code that is referencing an array of pointers to, for example, a FILE object (actually it's a union of FILE&_FILEX objects). How can Ghidra be made to recognise this better?
Presently, the decompiler produces stream = *(FILE **)((int)__poib[0] + iVar2);
where iVar2 is the pointer size multiplied by the index and is stored in the EDIregister to which the pointer size is added at the end of the loop.
It should be able to produce stream = __poib[i];
as the type definitions should be utilised during decompilation.
Note: i isn't created at all by the current decompiler, just iVar2!
As the plain example above is fairly understandable it's not too hard to interpret. However, once members become involved the decompilation misses them out completely, replacing them with an offset (as seen below) DeleteCriticalSection ((LPCRITICAL_SECTION)(*(int *)((int)__poib[0] + iVar2) + 0x20));
This should resemble DeleteCriticalSection (&(__poib[i]->lock));
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have some x86 32-bit code that is referencing an array of pointers to, for example, a FILE object (actually it's a union of
FILE
&_FILEX
objects). How can Ghidra be made to recognise this better?Presently, the decompiler produces
stream = *(FILE **)((int)__poib[0] + iVar2);
where
iVar2
is the pointer size multiplied by the index and is stored in theEDI
register to which the pointer size is added at the end of the loop.It should be able to produce
stream = __poib[i];
as the type definitions should be utilised during decompilation.
Note:
i
isn't created at all by the current decompiler, justiVar2
!As the plain example above is fairly understandable it's not too hard to interpret. However, once members become involved the decompilation misses them out completely, replacing them with an offset (as seen below)
DeleteCriticalSection ((LPCRITICAL_SECTION)(*(int *)((int)__poib[0] + iVar2) + 0x20));
This should resemble
DeleteCriticalSection (&(__poib[i]->lock));
Beta Was this translation helpful? Give feedback.
All reactions