How do I find where in the code a particular Windows Resource is used?

Question

I'm trying to reverse engineer a Windows program. Using PE Editor, I find that the string in question - which I'm interested in - has got id 2820. The string is in this format: "Some text, some text: %s". Whenever this string appear in the program, about once per minute, five bytes (ASCII letters) appear where "%s" is. The letters seems to be random, but I think they are not and I'm interested to see what they are exactly. Hence the reverse engineering.

However, I have a hard time finding in the disassembly exactly where resource id 2820 is fetched. There's a lot of functions/procedures involving LoadResource() / LockResource() but there is no obvious constant of 2820 anywhere.

Question: Is it possible, using whatever debugger, to put a breakpoint on resource ID 2820 that will halt execution as soon as the resource value is fetched?

If not, what other approach can I use to find where in the code the resource is fetched, so I can dig deeper to see how the five bytes are created?

Answer 1

You can use conditional breakpoints with WinDbg using syntax similar to below, adjusting as necessary depending on specific APIs used.

32-bit Application (x86)

bp /w "poi(@esp+8) == 2820" user32!LoadStringW
bp /w "poi(@esp+8) == 2820" user32!LoadStringA

64-bit Application (amd64)

bp /w "@rdx == 2820" user32!LoadStringW
bp /w "@rdx == 2820" user32!LoadStringA

Answer 2

As for static approaches, I like to use IDA's immediate search for this kind of thing. Search -> Immediate value..., and then put in the resource ID 2820, as in:

IDA will give you a (usually small) list of places where the number 2820 is used in the code. The larger the number, the fewer false positives one tends to see in the output. There are a few compiler optimizations that may cause this not to work, most particularly switch statements compiled via binary search (e.g. if the target uses a switch statement to inspect an ID that Windows sends back as part of a window message), but in your case (string IDs), this almost certainly won't be a factor.