Continuing with my preliminary exploration of Ghidra. If we continue with the call to RegOpenKeyExA from last time (yes, I know this code is unreachable as we discussed last time, but let's keep going anyway).
If we look back up at the first parameter, we see 0x80000001. Off the top of my head, I don't remember which key that is (well, actually, I've been doing this long enough that I do, but let's pretend that I don't). In IDA, I'd right-click on that hex value and choose 'Use standard symbolic constant' to replace that with the constant definition from one of the Windows header files that defines those. It turns out, Ghidra lets us do this, too. In Ghidra, right click and choose 'Set Equate' and it pops up a dialog box similar to IDA's from which you can choose the proper constant to use in place of the hex value.
Just like in IDA, if you know the constants for registry keys start with 'HKEY_' (or you looked it up on MSDN, now known as, docs.microsoft.com) you could start typing that and it would narrow down the choices. In this case, it is easily visible. So, double-click on 'HKEY_CURRENT_USER' or click and choose OK and the constant is replaced. Notice that you have the option here to just do the substitution for this one instance or across the entire program. I'm going to leave this at the default, but there may be times when you want to replace the hex value with the symbolic constant everywhere (nearly every time I teach FOR610 a student will ask me if IDA has that capability and, if it does, I'm not aware of it).
Looking above that at the second parameter, I usually want to know which particular subkey is being opened. In IDA, I just hover over the label for the string and it shows me the entire string. In Ghidra, if I hover over it, it shows me part of the string, but not the whole thing. Hmm... That is a bit of a problem. If I double-click on the label, both IDA and Ghidra take me to the place in memory where the string is located, but again, Ghidra doesn't show me the entire string. In the hex column it only shows me the first 9 bytes in hex and then gives me the ellipsis, but in the string part, it still doesn't show the whole thing. It shows the first 40-something characters and then the ellipsis.
In hunting around, I was not able to find a setting to increase that, though I'm sure there must be a way somewhere. If not in a setting, then in the code itself (which is now available on github). You can see the entire string though, if you go through the Search menu (choosing 'For Strings...' option). In this case, since I could see the CurrentVersion substring, I just searched for that and found the following.
In the end, though, I realized I didn't need to go to that much effort, there was a much easier way to see the string. Just go back to the decompiler window. As I mentioned in the previous diary, one way that the decompiler makes our lives as malware analysts much easier is it saves us the effort of having to try to match up the PUSHes or MOVes to figure out which parameter is which. This is especially true when you get into 64-bit malware on Windows which uses a lot more fastcall and the MOVes into registers may not appear in the order you expect. So, when I glance over into the decompiler window, I see this.
Very nice, it has my symbolic constant, it shows the entire string. That's just about everything I think I need to know about that API call.
I think that's enough for this diary, I have at least one more to come (probably next week). Again, as I mentioned in the first 2 entries in this series, this is all just from a very brief time playing with Ghidra. I haven't had a lot of time to dig deep yet, but so far, I'm liking what I'm finding. If you have any thoughts, comments, corrections, or tips of your own, please e-mail me or use the comments below.
Jim Clausing, GIAC GSE #26
jclausing -at- isc [dot] sans (dot) edu
I will be teaching next: Malware Reverse-Engineering Challenge - SANS New York City 2019
.png "Blog_teaser_images_(22).png")
