Unable to put input value into interpreter.

[pypygeek]

trafficstars

Hello, Unable to put input value into interpreter.

OS : Ubuntu 18.04.5 LTS

Why don't Ghidra for the input value? Where can I enter the value of the Ghidra?

Thx.

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
        char userInput[50];

        printf("Input key : ");
        gets(userInput);

        int cmpResult = strcmp(userInput, "2021-keygen");

        if(cmpResult == 0)
        {
                printf("Verification Completed!!\n");
        }
        else printf("key value is not valid!\n");

        return 0;
}

[d-millar]

@pypygeek hmmm, very interesting example - thanks for supplying the code! will try it out today and get back to you. @nsadeveloper789 understands the intricacies of the signal handler logic for gdb a bit better than I do, so will see if he has a theory as well.

[d-millar]

From @nsadeveloper789: You're getting that signal because the target is not able to read from the pty Ghidra allocated for GDB. Unfortunately, the sharing of a pty between GDB and the target application is a bit difficult to keep track of. So, I'll start with how we intend to deal with that in the future, and then follow-up with two potential workarounds.

Future stuff (hopefully) - we have an interface for transporting target console IO over the debugger connection, but no connector implements this, yet. The GDB one could do it somewhat easily be allocating yet another pty and instructing GDB to start the target attached to that pty. The connector would then implement the IO using that pty. ...but, we're not there yet.

Workaround 1) Start a separate console, e.g., xterm, which will allocate a pty; get its pty using the tty command; sleep 10000000 (yes, it's a hack); and then use set inferior-tty [TTY] from the GDB console in Ghidra before launching your target. Use the "quick launch" button in the Objects window to launch on the existing connection. This should let you interact with the target using that xterm. Be wary of hitting Ctrl-C there, as that will probably kill sleep instead.

Workaround 2) Use the lesser-known (and less-tested) "use existing session" option when connecting Ghidra to GDB. It's a similar hack to the first, but will let GDB handle the pty sharing. This will cause Ghidra to allocate a pty for GDB, but it won't actually start GDB. So start gdb in, e.g., xterm; tell Ghidra to connect and check the "use existing session" box; while it's connecting, look for it to print out the pty name (probably in the Debug Console); then issue new-ui mi2 [TTY] in your already-running gdb. This should let you use GDB and interact with the target in the usual fashion, in addition to having Ghidra connected to the same session.

In both cases, your mileage may vary.

[ghost]

@d-millar Thank you for kind comment. I leave a way for those who wander.

Order of Tasks

1. Check Terminal tty
2. Terminal input sleep 10000000
3. Ghidra Interpter input : set inferior-tty [TTY]
4. run

I solved the problem, so you can close the issue.

Thank you.

[d-millar]

@pypygeek‘s thank you notwithstanding (thanks @pypygeek!), I think we should leave this one open until we have a more intuitive solution

[naveensaigit]

While @pypygeek's solution is perfect for complex situations, if someone prefers to skip the complicated process of connecting the shell to Ghidra's GDB, you can just create an input.txt and debug using the following command - run < input.txt.

Also, I noticed that Ghidra's GDB doesn't have support for multiline interactions, eg Python GDB integration. A workaround for that would be as follows - If this is the multiline Python code you want to run inside Ghidra's GDB

code = '''import gdb
gdb.execute('file <filename')
gdb.execute('break <breakpoint>')
gdb.execute('r')
'''

You can run the following -

python code = "import gdb\ngdb.execute('file <filename')\ngdb.execute('break <breakpoint>')\ngdb.execute('r')"
python exec(code)

This method would work even for complex Python code which may include for loops, functions, etc

[d-millar]

NB: This problem has morphed slightly with the release of the traceRMI variants. "Continue" from the terminal allows for input; "continue" from the toolbar button throws a SIGTTIN, which then repeats ad nauseum.

[nsadeveloper789]

Eh, this is a bit of a limitation in GDB. I suspect it will depend on the version, platform, target, etc.... If you get SIGTTIN from using the toolbar controls, then just repeat the command using the Terminal instead. It's possible you'll still get SIGTTIN. Oddly enough, trying from the terminal a second (or third) time may work.

The other way (and you might prefer this anyway, based on your set-inferior-tty solution above) is to check the Inferior TTY box in the launch dialog for GDB. This will create two embedded terminals in Ghidra: one for GDB, and a second for the target. In this case, continue from either GDB's terminal or from Ghidra's control bar will work as expected. You can provide input via the target's terminal (no more SIGTTIN).

Also, multi-line interaction works now.