0

Consider the following disassembly:

mov     dword ptr [rbp+430h+var_458], 690068h   ; L'i' + L'h'
mov     dword ptr [rbp+430h+var_458+4], 2E0064h ; L'.' + L'd'
mov     dword ptr [rbp+430h+var_458+8], 6C0064h ; L'l' + L'd'
mov     dword ptr [rbp+430h+var_458+0Ch], 6Ch   ; 'l'
; -> L"hid.dll"

This is structurally similar to the disassembly from this question, except that the characters are wchar_t instead of char and moved dword-wise instead of byte-wise. The comment on the last mov was automatically added by IDA, I had to add the others myself.

The 6Ch in the last mov line could also be treated with R to change the representation to what's currently shown in the comment.

Not so with the other lines. R has no effect there, although IDA has no trouble deciphering a dword-wise copy of char-based strings as evidenced in this blog article (example from there: 70747468h -> 'ptth' -> "http").

I know of the stackstrings plugin, but cannot use it due to its dependency on Python 2.x!

Is there a configuration setting (similar to string types and data carousel) to teach IDA the ability to use R in these cases to make better sense of those wchar_t-based stack strings?

IDA Pro version: latest (7.7.220218)

2

1 Answer 1

-1

The problem was caused by a hex-string in the middle of the wchar_t string! The stackstrings plugin correctly handles such strings, but IDA does not.

For example, in the following code: mov dword ptr [rbp+430h+var_458], 690068h ; L'i' + L'h' mov dword ptr [rbp+430h+var_458+4], 2E0064h ; L'.' + L'd' mov dword ptr [rbp+430h+var_458+8], 6C0064h ; L'l' + L'd' mov dword ptr [rbp+430h+var_458+0Ch], 6C68h ; 'lh' ; -> L"hid.dll" IDA correctly displays the string as "hid.dll" when the last mov is changed to: mov dword ptr [rbp+430h+var_458+0Ch], 6C6Ch ; 'll' ; -> L"hid.dll"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.