Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Ghidra decompiler: c_str() used in phantom string?
I loaded a binary into Ghidra for analysis.
The decompiler says
undefined8 main(void)
{
basic_ostream *pbVar1;
char *pcVar2;
[--snip--]
pbVar1 = std::operator<<(pbVar1,"PXZ ");
pcVar2 = (char *)std::__cxx11::basic_string<>::c_str();
pbVar1 = std::operator<<(pbVar1,pcVar2);
pbVar1 = std::operator<<(pbVar1,"<<");
std::basic_ostream<>::operator<<((basic_ostream<> *)pbVar1,std::endl<>);
}
I'm clueless about the meaning of the pcVar2 = line. I would expect c_str to be the method of some given string, e.g. std::string const s("Emplary"); const char* p = s.c_str();, but what is that string in the present case?
I can confirm that something is getting inserted as the binary prints "PXZ AX1<<", but it's hard to figure whence exactly this middle part is coming.
1 answer
Maybe Ghidra's decompiler can't handle C++ syntax that well.
In that case one has to fallback to assembly in the listing view.
Leading to the c_str() call is
00102b51 e8 8a f7 CALL <EXTERNAL>::std::operator<<
ff ff
00102b56 48 89 c3 MOV RBX,len
00102b59 48 8d 85 LEA len=>local_448,[RBP + -0x440]
c0 fb ff ff
00102b60 48 89 c7 MOV RDI,len
00102b63 e8 f8 f6 CALL <EXTERNAL>::std::__cxx11::basic_string<>::c_str
ff ff
Therefore, local_448 is the string whose c_str() method is being called. This is easy to figure in this case even without knowing the calling convention given that almost nothing else is being set up between the adjacent << and the c_str calls.
But just to make sure I looked it up and that matches indeed the calling convention used by GNU GCC:
The GNU g++ compiler treats
thisas the implied first parameter to any nonstatic member function and behaves in all other respects as if the cdecl convention is being used.— The Ghidra Book, The Definitive Guide, by Chris Eagle and Kara Nance
and
For 64-bit x86 binaries, cdecl varies by operating system; on Linux, up to six arguments are placed in registers RDI, RSI, RDX, RCX, R8, and R9, in that order, and any additional arguments spill onto the stack.
— Ibid.
Also there is nothing special about c_str, other string methods such as length are likewise problematic in the decompiler view but can be likewise correctly analysed in the assembly view.
0 comment threads
0 comment threads