With Microsoft Visual C++ executables, I often run into decompilations like this:
void __cdecl Pbdf::ReadString(char *dst, Pbdf *pbdfOrLength)
{
Pbdf *pbdf; // esi
pbdf = pbdfOrLength;
Pbdf::ReadBytes(&pbdfOrLength, 1, pbdfOrLength);
Pbdf::ReadBytes(dst, (unsigned __int8)pbdfOrLength, pbdf);
dst[(unsigned __int8)pbdfOrLength] = 0;
}
The function is actually more like this (as seen in a Watcom executable doing the same thing):
void __usercall Pbdf::ReadString(char *dst@<eax>, Pbdf *pbdf@<edx>)
{
unsigned __int8 length; // [esp+0h] [ebp-14h]
Pbdf::ReadBytes(pbdf, &length, 1u);
Pbdf::ReadBytes(pbdf, dst, length);
*((_BYTE *)dst + length) = 0;
}
So, from a Pbdf file-like struct, it's reading a single byte determining the number of following bytes to read into a buffer, and terminates that buffer with a 0.
However, in the MSVC decompilation, you can see it merged the length and Pbdf struct into one variable, causing me to name the variable "pbdfOrLength".
Is it somehow possible to tell the decompiler to "split" these variables up / handle them as two separate ones, to get an output similar to what is seen in Watcom?
enum
will sometimes cause unrelated variables to self-convert to the sameenum
. This happened again yesterday, in applying an enum forsocket(2, 0 ...
akasocket(AF_UNIX, SOCK_STREAM...
all mybool
returns changed toreturn SOCK_STREAM;
. TBF 7.5 is otherwise fairly impressive. e.g. I haven't had to map v1= a1; v2 = a2; v3 = a3 once!