Vanishing Address/ Deadlisting vs. Running Process

Posts 1–15 of 22 · Page 1 of 2

Okedoke

I have this address. Seems simple enough right. Some other people tell me they found it, supposedly by searching for it in memory. However when I look at a deadlisting of the code in Olly, IDA, or whatever... I can't find it.

It vanishes... poof!
So I'm wondering, is it because the program isn't running, or something else. That's my theory currently. In any case, I can be more specific, if necessary. I just try to make my questions as generic as possible so that I can apply it to any situation.

could be a few reasons.. the first and most probable one being that the target is PACKED or ENCRYPTED.. these programs are usually unpacked or decrypted into memory at runtime, the deadlisting you see will be very different to a live target.. not sure if thats what you mean.. give us a few more specifics if you can.. easier to work with specifics.

Well lets see:

Someone found a value up in the 0x30000000's so I naturally tried to find that same value in my game engine's deadlisting. However the way he describes it. It is an instruction and not a value, that I should NOP in order to dampen recoil. Now the Engine.exe comes with a couple .dll's as well so Im wondering if its stored in the, because just in the deadlisting alone I can not jump to or look at any memory address outside the 0x00000000 to 0x10000000 range. So Im kind of wondering why my deadlisting is so different from the actual game that I can not see these instruction. DMA I can understand, but these are instructions, so Im not sure how they can be there in the game and not in the .executable when I view it.

Most likely performed on a running target.
Thats how I got the addies for KW2 and Natl. bloodsports(for CInput).

Just run the game, attach olly to it, and have fun staring at disassembly

Figure out which DLL gets loaded where, theres probably one loaded around 0x30000000 for the game you're debugging, which I asume is CA seeing as you mentioned Engine.exe

in olly > executable modules gives you a nice list of modules loaded.

Ill give you all the occurances of your problem and what they could be..

1. Code is situated in an external .dll file loaded at runtime. (you wont see this in deadlisting)
2. Code is packed, encrypted etc.. and unpacked at run time (you wont see this in deadlisting)
3. Java applets allocate memory and store code in them on the fly at runtime working within its own virtual machine. (pain in the arse.. wont show up on deadlistings)
4. Code shifts.. the code is situated in a dll that ISNT!! static.. best way to find out is to load the dll into ida.. if it has an address range of 10000000 then its more than likely going to be placed wherever it can find space at runtime(SHIFTING).. which means even if you are running a live target u wont find the code at the offset given to u..

Im pretty sure your problem is either 1 or 4..

solution to 1. run the live target.. goto the address given to u.. check the code is there.. if it is.. then just make your trainer attach to the main exe as usual and it should have no problem altering the code at your location..

if you want to find it in a deadlisting.. then find the name of the dll.. load it into your disassembler and use the opcodes of the instructions as a search string.. hopefully there wont be too many occurances and you will find your code inside the dll with no problems..

solution to number 4 is a little more complex.. not much.. but relies on you being able to code a small addition to your trainer engine that reads the list of dlls in a game and compares the size or the name to find the base adress then you add the offset of your instructions.. there is a very good tutorial written by my friend spookey.. its all over the net if u wanna learn about this..

Originally Posted by [sheep]

Im pretty sure your problem is either 1 or 4..

solution to 1. run the live target.. goto the address given to u.. check the code is there.. if it is.. then just make your trainer attach to the main exe as usual and it should have no problem altering the code at your location..

if you want to find it in a deadlisting.. then find the name of the dll.. load it into your disassembler and use the opcodes of the instructions as a search string.. hopefully there wont be too many occurances and you will find your code inside the dll with no problems..

solution to number 4 is a little more complex.. not much.. but relies on you being able to code a small addition to your trainer engine that reads the list of dlls in a game and compares the size or the name to find the base adress then you add the offset of your instructions.. there is a very good tutorial written by my friend spookey.. its all over the net if u wanna learn about this..

I want to go with door number four because it sounds really cool, but all I need is door number one for now. And thanks for the tip about searching for the opcode. As far as three and two, I have a unpacked Engine.exe and I would think Java would be rather easy to look through because there are very accurate decompilers for bytecode... not that I would know how to alter it externally, never really got that far in Java. =/

C++ stuff:

To get the base address while running:

Code:

GetModuleHandle("example.dll");

Then use this to access e.g. an int pointer(where 0x1337 is the offset ofcourse):

Code:

int *pPointer = (int*)GetModuleHandle("example.dll")+0x1337;

A little bit more complex but pretty much does the same:

Code:

BYTE *pGetModuleBase(int processID, char *pModuleName)
{
	HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, processID);
	if( hSnapshot != INVALID_HANDLE_VALUE )
	{
		MODULEENTRY32 me32;
		me32.dwSize = sizeof( MODULEENTRY32 );
		if(Module32First(hSnapshot, &me32))
		{
			do
			{
				if(!strcmp(me32.szModule, pModuleName))
				{
					return me32.modBaseAddr;
				}
			} while(Module32Next(hSnapshot, &me32));
		}
	}
	return NULL;
}

You call it like this:

Code:

BYTE *pPointer = (BYTE*)pGetModuleBase(processID, "example.dll")+0x1337;

The first one requires you to be in the targets memory space, while the second one can be used externally(use writeprocessmemory to write to the location).

not sure if you can Invoke these in ASM(as I don't code in ASM

) if you can't you can always compile with MSVC and then copy the disassembly and start working it back to .368

Originally Posted by Hell_Demon

) if you can't you can always compile with MSVC and then copy the disassembly and start working it back to .368

Hmmm.... me neither. Depends if they're in the .inc file that comes with the MASM package. If not I can make my own include file, couldn't be that hard. Not that I will ofcourse. Im gonna be using the easiest way, cuz Im lazy, but it would be cool to make a program that could externally gather all the base pointers for all the .dll imported into a PE, but what it they were dynamically allocated like sheep mentioned? Oh well why am I thinking about this. My problem has been solved twice over. Thanks guys!

Originally Posted by why06

it would be cool to make a program that could externally gather all the base pointers for all the .dll imported into a PE

File attached below.
Link to a sample dump(firefox.exe)
Codens:

Code:

#include <windows.h>
#include <TlHelp32.h>
#include <iostream>
#include <conio.h>
using namespace std;

void DumpProcessModuleList(DWORD processID)
{
	HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, processID);
	if( hSnapshot != INVALID_HANDLE_VALUE )
	{
		MODULEENTRY32 me32;
		me32.dwSize = sizeof( MODULEENTRY32 );
		if(Module32First(hSnapshot, &me32))
		{
			FILE *fp;
			fp = fopen("dump.txt", "a");
			fprintf(fp, "Process: %s ProcessID: %d\n---\n", me32.szExePath, processID);
			do
			{
				fprintf(fp, "Module: %s Base: %X Size %X \n",me32.szModule, me32.modBaseAddr, me32.modBaseSize);
			} while(Module32Next(hSnapshot, &me32));
			fprintf(fp, "---\n\n\n");
			fclose(fp);
			cout<<"Module list dumped! Check dump.txt!\n";
		}
	}
}

DWORD pdGetProcessID(char *pProcessName)
{
	HANDLE hProcSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
	if( hProcSnap != INVALID_HANDLE_VALUE )
	{
		PROCESSENTRY32 pe32;
		pe32.dwSize = sizeof(PROCESSENTRY32);
		if(Process32First(hProcSnap, &pe32))
		{
			do
			{
				if(!strcmp(pe32.szExeFile, pProcessName))
				{
					cout<<"Process: "<<pe32.szExeFile<<" PID: "<<pe32.th32ProcessID<<endl;
					return pe32.th32ProcessID;
				}
			} while(Process32Next(hProcSnap, &pe32));
		}
		return -1;
	}
}

int main()
{
	char pProcName[64];
	cout<<"Enter the process name(e.g. engine.exe): ";
	cin>>pProcName;
	DWORD pID = pdGetProcessID(pProcName);
	if(pID != -1)
	{
		DumpProcessModuleList(pID);
	}
	else
	{
		cout<<pProcName<<" could not be found!"<<endl;
	}
	getch();
	return 1;
}

ModuleDumper.rarattachment deleted · 2 downloads before removal

What is a deadlisting. Based on the context I am assuming it is a dissassembly? Like basically the disassembly of the target binary? I have only started to recently see that term being used.

@demon.. thanks to the hard work of iczelion and hutch + many others, any api call you can use in C++ you can use in asm aswell.. and actually.. in theory there is nothing u cant call in asm as long as you have the correct include/lib files.. even directx.. though a lot of work is sometimes needed in the conversion..

@zeco... Deadlisting is a FORM of disassembly.. as you can have a disassebly of a LIVE TARGET also.. DEADLISTING is a file (usually .exe) that is not being RUN at the time of disassembly.

Originally Posted by zeco

What is a deadlisting. Based on the context I am assuming it is a dissassembly? Like basically the disassembly of the target binary? I have only started to recently see that term being used.

A deadlisting is the disassembled machine code of an executable files (including .dll's and I suppose perhaps some other file types) before it as been loaded up into memory, or while the code is not being executed, therefore dead. =P

EDIT: my bad, lil slow there. what he said.

@HD: Thanks a lot.

I'll have to look into the Snapshot thing or whatever, looks helpful.

No if only I could have a $100.00 USD too.... any takers? xD

Deadlisting is a very oldskool phrase.. which is why you prob havent heard it much.. it has been around since the invention of the very first programs.. when programs used to come on sheets of card

i think BA has a few he coded way back when

hehe just kiddin..

Oh ok. It's just when referring to deadlisting as you call it, I usually simply call it disassembly. When I am talking about disassembling a live target, i usually refer to that as debugging.

Thanks =)

lol Wouldn't surprise me if Why picked up the term from me since I know we've talked about it before.

Besides you gotta admit - something nice (ok nostalgic if you wish) about sitting on the couch with an old fashioned print out (or even a txt file) of disassembly generated in W32Dasm8.93 and figuring stuff out that way. Then again I also prefer books over PDFs / CHMs etc..