Problems with Visual Studio Created C/C++ ?!

[Marc-Bender]

Describe the bug Ghidra seems to not like the executables that are written in Visual C++ compiled with Visual Studio 2017 Enterprise. In particular it does not recognize the library functions (e.g. printf) (in contrast to that it works for the basically same Code compiled with gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)). also it seems to not recognize objects of type 'const char * []' or in other words a Array of strings. additionally it seems like its discriminating for loops.

To Reproduce Steps to reproduce the behavior:

1. fetch the executable for my Baby-Shark-singing-Program as found here: https://github.com/Marc-Bender/Baby-Shark/tree/binaries
2. decompile it with everything default

Expected behavior should be clear…?!

Environment (please complete the following information):

• OS: [Windows 10 x64]
• Java Version: [11.0.2]
• Ghidra Version: [9.0 Build PUBLIC 2019-FEB-28 1236 EST]

[ghidra1]

Are you using a PDB for type information? Is so, there is a known issue where no distinction is made between char* and char[n] or multi-dimensional arrays when comparing PDB data vs source code. PDB seems a bit deficient in this regard.

Could you please provide some samples of expected data types vs results in Ghidra and where they occur (i.e., function signature or data).

[Marc-Bender]

well let me just take screenshots of just About everything that happens… (to be honest i have no clue what a pdb is ...)

at this Point i have to ask myself where the main function is because there is no such function recognized so lets use the educated guess that the strings Baby Shark Mommy Shark and so on are used there

therefor search for strings

lets jump to the Memory Location of that string and search for the use of that string jump to that single occurence… this now Shows something that Looks remotely similar to the original source Code but: you should see that this is hardly anything useful to the average Joe when compared to the original Code sideby side.

[Marc-Bender]

actually let me load a grab a gcc compiled Version of that and demonstrate what happens then well this now Looks quite different it still Shows some strange stuff but it atleast is able to make matters a Little more human intelligable...

[emteere]

Can you post what is located at 0x411960, and also the address that 0x411960 refers to?

The function name and arguments are not being pulled up from the thunk to the external library. My suspicion is the binary was compiled statically and the call to printf or printf has not been recognized for some reason.

[Marc-Bender]

@emteere actually the suspicion Sounds plausible. but cant you figure out the Memory Contents yourself? as i already pointed out the Code for the Program i tested ghidra with and found this issue is here on GitHub (link in the initial post) and i actually did post the executable there as well. so everything should be reproducable by anyone without any assistance of mine.

[Ytrog]

I have a similar issue with basically the hello world example 🤔

[niedabao1]

i have same problem,look like it's can't identify C lib function

[julianxhokaxhiu]

Having basically the same issue, decompiled code is really hard to be understood. Using the latest Ghidra 9.1.2 Public release.

[schurma]

I experienced the same issue with Microsoft Visual Studio Professional 2017.