Ghidra's Strings window doesn't show a string but IDA's String window does

[3N4N]

It's about a CTF challenge. They added the flag in string format in the binary. IDA shows the flag in its Strings window (Shift+F12), but Ghidra's Defined String window doesn't show that flag. Moreover, in the address where the flag exists, Ghidra shows undefinedl or something (screenshot below). I don't know how to use IDA so can't tell if IDA's Listing window also shows undefinedl.

I would've opened an issue but don't know what info I should give so thought I should chat around first.

[3N4N]

I guess Ghidra's Defined Strings window shows the strings actually defined with LEA or something? And IDA's Strings window shows any string it finds, like unix's strings ./file_name command?

[dragonmacher]

Yes, the Defined Strings window only shows applied String data types.

You can also try searching for strings from the menu Search -> For Strings...

[3N4N]

 Yes, the Defined Strings window only shows applied String data types.

Makes sense. Is there a way I could find all valid character strings in the binary file as IDA does? Valid as in not the stray characters output by unix's strings command.

[dragonmacher]

I think using the string search feature mentioned above is your best chance. Ghidra analysis will define some strings. Other string content will be missed by analysis. You can use the string search feature to view potential strings. From the search results you can create defined strings at any location you please.

[3N4N]

The problem was that Ghidra didn't recognize the data as a string. When I did Right click -> Data -> Terminated C String, the flag showed up in the Defined Strings window. Isn't it a bug in Ghidra that it didn't recognize a string but IDA did?

[astrelsky]

The problem was that Ghidra didn't recognize the data as a string. When I did Right click -> Data -> Terminated C String, the flag showed up in the Defined Strings window. Isn't it a bug in Ghidra that it didn't recognize a string but IDA did?

The usual cause for this is that the string is too short (less than 4 characters). That clearly is not the case here. If it is because of the loader applied undefined1 array then I would consider it a bug in my opinion.

[dragonmacher]

If it is because of the loader applied undefined1 array then I would consider it a bug in my opinion.

This would be a Ghidra mistake if one of our analyzers laid down the undefined1 array, thus blocking the Strings Analyzer from detecting the string data. However, if the user applied the datatype instead of Ghidra, then that would be user error.

Isn't it a bug in Ghidra that it didn't recognize a string but IDA did?

I think of an RE tool as kaleidoscope that shows you some vague resemblance of the original source code. IDA and Ghidra both recover varying levels of information during analysis. Neither tool will find everything; each tool may perform better than the other depending on the architecture, tool version, analysis settings and such. To get the most out of these tools, the user is expected to aid in the recovery process by finding and applying functions, data, comments, etc. Further, the information recovered between versions of Ghidra may change, due to how our analyzers are changed between versions. In this case, we don't think of the analysis differences as bugs, but just different reflections of the original binary.