Getting decompilation to display strings assigned via SIMD instruction

[leechristensen]

How does one get the decomplication to to display strings when SIMD instructions like MOVUPS/MOVAPS are used to assign the string? For example, in the screenshot below, we can see in the assembly that the data is defined as a unicode string but the decompilation doesn't display the string:

Relevant as well: https://reverseengineering.stackexchange.com/questions/24974/how-to-improve-ghidra-decompilation-of-sse-instructions

[Wall-AF]

Try marking the data as constant. Right click on the data (in the Listing:Panel), go into the Data submenu, open either the Settings... (for a one off) or Default Settings... dialog, change the Mutability to Constant.

[leechristensen]

Yeah, I had tried that as well with no luck:

[leechristensen]

Here's the target file in case anyone wants to play along. See the GetUserDirectory function

[emteere]

In the latest Ghidra 11.2, which should be released in a few days, and the main branch, the decompiler now recovers stack strings and there is initial support for optimized heap strings. The implementation may require more work for strings built using SIMD registers, however it might work for your case.

[leechristensen]

Thanks, I'll give it a try when it's released and report back!

[leechristensen]

The default analysis still results in a similar issue due to it not recognizing puVar1's type (it's an undefined pointer):

Switching puVar1 to a LPCWSTR fixes it up though!

FWIW, both BinaryNinja/Ida pickup the string type default. Should this still be filed as an issue, or something separate?

[emteere]

I think detecting the type of the variable from the string already created in memory would be a worthwhile change. I can't speak to how easy that change would be. I've created an issue from the discussion #6985. Feel free to augment the issue.

I've also put in an internal ticket to consider using the fact that a string has been defined in memory that is being loaded into the SIMD register.