Help with disassembling an .exe to find a variable name/adress - Developers

Following situation: I'd like to change Valves vrad.exe to customise the generation of lightmaps a little more. I'm not going to disassemble and recompile it (I have some basic knowledge about programming, but I'm pretty sure, I'd be screwing up the whole thing). Instead I want to find the adresses of parameters to modify the running program (with e.g. CheatEngine) to make bounced light brighter and stuff like that. The problem is now finding the adress for these variables. The problem is that they're static and I can't find them through the exclusion-technique, I'd use on changing variables. My only chance to find them is to decompile the program and make sense of the code. So far I could translate most of it into Assembler, but the only working disassembler I found is pretty old, so many code-segments were missing. Also, It's Assembler, which would take quite a while to make sense of... My questions now are: Is there a better way to do this? Can I 'translate' assembler into a higher language (maybe at least something I can make more sense of?) Does somebody have experience with decompiling and can give me some hints?

Pretty sure that the address of a variable in memory is determined whenever it's initialised and is not something you can know beforehand.

-snip, I'm wrong as usual-

If you want the memory address, the best you can use is Cheat Engine, though you'd have to know the value beforehand and it's not likely to be the only address storing that value.

IDA and Ollydbg are pretty nice, IDE is a very good dissembler that also has some ASM->C functionality (all though this rarely every works out to be more readable then the ASM)(If you feed it Linux/Mac libraries you will get function names) Ollydbg is a debugger capable of a lot of cool things. However, doing things like this isn't easy. instead i suggest you find yourself a copy of the Source engine 2007 Leaked Source and use the VRAD thats in there. I think that the 2007 VRAD should work out of the box but if it doesn't you can use the source to help you find what you need in the debugger/dissemblers.

[QUOTE=OldFusion;40197672]However, doing things like this isn't easy. instead i suggest you find yourself a copy of the Source engine 2007 Leaked Source and use the VRAD thats in there. I think that the 2007 VRAD should work out of the box but if it doesn't you can use the source to help you find what you need in the debugger/dissemblers.[/QUOTE] That sounds like a good option. Probably hard to find though. (Not quite the gentleman way, but I don't intend to pass it on to anyone)

VRAD source is not leaked, it is offered by Valve, you can see it from the Source 2007 SDK, in the 'Everything_SDK-2005' solution. It is made of two projects, vrad_dll and vrad_launcher, the first one seem to do all the job, while the second is the .exe for calling the library (i've not studied them). I gess you have done this, take a look at all vrad parameters, just in case you can find what you want to change here. [url]https://developer.valvesoftware.com/wiki/VRAD[/url] By the way, dissasembling a program in order to modify a constant value may become a really tough task, because if the address of the value is not needed for an external function, most compilers tend to translate the variable as a inmediate value, since it is faster than reading from an address, so the variable value could appear in every place it is used.

Yeah, peppin is right about the VRAD also being in the official SDK. I just assumed something like that wouldn't be in there so i din't check it.

Great. I got the Everything_SDK-2005.sln and found exactly the variables I was looking for: [code]float gamma = 0.5; float indirect_sun = 1.0; float reflectivityScale = 1.0;[/code] Now, I'll see if I can compile it and get it running, but this is already a huge step forward :D

You could probably just patch the correct values directly into the binary. Disassemble and find the correct function. In the function, look around for FLD instructions which load values from memory addresses. The bad news is that since some of those constants are 1.0, there'll probably be FLD1s, so you need to patch the instructions as well as just constant values.

From Visual Studio 2012, if you set your solution in release mode, and disable /SAFESEH from linker options in the Vrad_dll project, Vrad_dll and Vrad_launcher compiles perfectly. I haven't been able of compile it in debug mode. PD: compile or compiling? sorry for my poor english.