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.

Post History

60%

+1 −0

Q&A Ghidra decompiler: c_str() used in phantom string?

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 ...

posted 1y ago by nteodosio‭ · edited 1y ago by nteodosio‭

Answer

#2: Post edited by

nteodosio‭ · 2023-11-18T18:10:58Z (about 1 year ago)

Copy Link

Raw

Markdown

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 `this` as 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.

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 `this` as 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.

#1: Initial revision by

nteodosio‭ · 2023-11-18T18:07:19Z (about 1 year ago)

Copy Link

Raw

Markdown

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 `this` as 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.

Communities

Post History