I apologize if this question is too elementary, but I am not sure what I am doing wrong.

I have certain .exe file that I have disassembled with IDA.
I tried to find a string that I need to figure out the protection.

The string is in unicode format, but I could not find by searching it in the IDA disassembly window, Hex window or strings window.

I searched the string with a Hexeditor, and found it at raw offset 1895E2
When I try to get to that offset in IDA, it is beyond the end of the IDA disassembly and the Hex window, after correcting for the the base address.

I searched for other, non-Unicode strings and found them at the right places, for instance at address 51F5E2 in IDA hex window, correctly corresponding to the address 11F5E2 that the HEXeditor gave, with a base address 400000.

But my unicode string would be at 5895E2 which is beyond IDA disassembly and IDA Hex .

I disassembled the file with W32Dasm and it correctly identified the String as a String Resource and cross referenced it correctly in the code.

IDA did not detect this Unicode string as a string resource, and did not labeled the code with the proper cross reference.

How do I make IDA locate the string resources and cross reference them?

Regarding the image at http://www.datarescue.com/idabase/unpack_pe/2a.gif, you want to make sure "Load resources" is checked.

You can't get IDA to xref the resource strings because they're "loaded" via Win32 API, not direct code references. I suppose you could create some IDC script to emulate the resource API functions and determine xrefs. Make sure to post the .idc here when it's done

Many thanks disavowed.

Someone (mammon and Quine) already tackled the problem.
I am posting their collection of .idc, available on the net.

Ahh, sweet. Never looked at that.

For archiving purposes, should the attached .zip above ever become inaccessible, it's currently archived at http://home.arcor.de/idapalace/idc/m_script.zip ("http://home.arcor.de/idapalace/idc/m_script.zip")

Not that it matters where it came from, since we're all one big happy family here :-), but that zip file, along with some others, is one I made up to preserve the info and gave to Yates for public safekeeping, initially here:
http://www.woodmann.com/yates/ida/m_script.zip

Just to add a little to this old thread, I've been using Winhex for years for patching, I just discovered, (DUH!), it has a great string search utility, either ascii or unicode, it will even search all files in a directory, now for the question, I found my string and it appears in a chunk of code at the end of my target that doesn't appear in any disassembler I've tried, it's not packed, and is straight C++ originally, I suspect that the parts I need to look at are in this section, anybody else run in to this? and why is this code inaccessable, I'm not even sure what to search for to learn about this.

SiGiNT

Never mind the question, I just answered it myself - MD5, Blowfish encrypted, now I know what to search for!

are you loading the resources with ida like i said above?

No, why would I want to make it easy? I guess I need to add to my acronyms, RTFT T=thread!

Thanx, It now shows up but in a pure data segment, no code there, back to the drawing board.

SiGiNT

did you try the .zip naides posted above to provide references into the resource section?

YEP!,

Downloaded it I'll work on using the scripts tomorrow. Work you know, kind of gets in the way of the important stuff.

SiGiNT

What happens when you do all of that and the string has no refs?

As was mentioned, you won't get xrefs to strings in a String Table in the rsrc section. LoadString or FindResource/LoadResource would likely be used. Monitor the API calls for the uID or lpType parameter you're interested in. Alternatively try memory read breakpoints on the memory location of the strings.

Kayaker