I have a DLL file that contains a string I need to change. Now when I load the DLL in W32DASM and open string references I can see the string, when I load it into something like ResHacker to change the string - the string isnt there.
I am guessing that this could mean the string is being pulled from a different file or is not part of the string table - how do I change this string, can anyone help me pls?

Thanks

Decompilers (like W32DASM) and debuggers find string references all throughout the code, not just in the string table. I don't know the exact method(s) employed, since I don't exactly have the source code for IDA sitting in front of me . But, strings have a pretty distinctive profile, so they aren't that hard to find. I would imagine that it starts by scanning the code for anything that looks like a string, and then walks through the code and marks off the ones that are actually referenced somewhere.

I'm not sure what you do with string that don't appear to be referenced. Some may be junk, but a lot of them probably do get referenced, only the decompiler doesn't know it. That would be one example of why intelligent decompilers (like IDA) that actually follow the code execution are preferable to static (deadlisting) decompilers like W32DASM.

Anyway, to answer the question you actually asked, your string probably isn't in the resource tables. You'll need a hex editor to find it. If you know the RVA of the string from W32DASM, you can convert that to the file offset so you know where to look. Or, you could just search for the string directly in the hex editor. It should be in plain sight, if you can see it with W32DASM.

There are search apps like 'grep', that are written to allow a search through files themselves. I couldn't tell you off-hand where you could find grep, but I think it's a Unix utility that can be used in Windows. You point it to a directory, or even the entire drive, and let it go.

Strings are often entered in Unicode. Each 8-bit byte is padded out to 16 bits. In a dead listing, byte will appear as 'b.y.t.e' . The period (.) doesn't mean it's a period, it's just that the hex editor can't reproduce that character. So, a text search wont find it unless the search engine is made aware of the unicode structure. Study unicode and look at how it is listed in a hex dump.

Alternately, you could follow up on your own point that the string is in another file. Don't assume anything, it may even be in a help file, or not even in the local directory. Hopefully it's not in a system file. Run other exe's, dll's and just about any executable through reshacker and see if you can spot it. It may not even be listed as a string. It may be part of a template. Look very carefully through every section of reshacker. To cut down your search, you can pretty well eliminate icons, etc.

The free tools from sysinternals are invaluable here. You can watch which files are being accessed, and that narrows down your search. That's partly what it's all about, learning how to make short cuts.

If you read +Orks tutorials, he urges you to think like the programmer. If you can't find the string as a unit, ask yourself why. Maybe the programmer doesn't want you to find it. So, how would you load a string so it couldn't be found by a dead listing? You'd load it one byte at a time and put pieces of it all over the place. To make it even tougher, you'd XOR them with a key byte and have them totally hidden.

Have you tried running the app through Boundschecker (or Smartcheck for VB apps). If you learn how to use these tools, you can pinpoint the string and see exactly where it's being loaded from, and how. Look up string functions in an API reference and see how each function manipulates strings. Then look for these string functions in Boundschecker. To save you scouring the entire app, learn how to use Boundschecker to zero in on where the string might be.

Using Sice, you can break near the string itself, and see where the string fuction is getting it from. In that case, all you do is run the app to the point where the string is being loaded and note where the bytes are being loaded from.

I would consider Tbone's advice to use IDA. WDASM is easier to use, but it doesn't have near the power of IDA. If you can't find something easily using WDASM, go to IDA.

you can use "strings": grab it at - guess where? - http://www.sysinternals.com/ntw2k/source/misc.shtml#strings

Regards, bilbo

thanks for the tip bilbo. I'm chuckling here at your nym. I was working at an oil refinery a couple of years ago, in the fall, on a night shift. It was getting cold, well below zero, and the steam from the refinery pipes in one area made the environment pretty eerie.

We were all bundled up against the cold, looking like overstuffed toys, wearing balaclavas, and hardhat liners that had thick quilted lugs, like Snoopy's ears, wrapping down around our chins. On top of that, we were all wearing safety googles and fireproof coveralls. It looked like a kind of Hobbit atmosphere. So we started calling one of the guys who worked that area, Bilbo Baggins. You need a bit of off-hand humour to survive those jobs.

You make me curious, WaxfordSqueers...
What had that guy different from others? The height? The age? The feet? The smell?

Regards, bilbo

no...he was actually a courageous guy. He was one of those types who did his job conscientously but who refused to kiss up to management. In fact, they fired him after an incident in which management had targeted the entire crew for an incident and threatened to fire all of them unless the perpetrator owned up. He stepped forward. It wasn't till after he got fired that we learned he didn't do it, he just took the fall for it. You don't find many selfless people like that.

We tagged him Bilbo Baggins out of respect and affection. I think he was the one who started calling his area, with the steam and everything, Hobbittville. Naturally, he got the name Bilbo Baggins. Some people command respect out of quietness and their actions. Even before he got fired, everybody respected him.