Printable View
What's the current status on memory hacks?
Anyone made anything useful?
I just installed Vista today. All I've done thus far is simple byte finds (infinite grenades, sniper ammo, etc.)
I was a bit angry to find that offsets are re-written into memory after every Load point in SP...
I really wish I took the time to learn point integers.
I don't have anything right now because....I don't have Vista or XP.
I'm helping Skyline who is making a 3rd Person app...though since we are coding it in VB.NET we encountered some problems...
Concars is working on a server application which has nothing to do with memory hacking.
We think this is the problem:
The Offset from the base address of the process never changes...what changes though is the base address of the process itself...
e.g
Halo1.exe + 5 = 400000 + 5 = 400005
Halo2.exe + 10E42B = ???? + 10E42B = ????
and the base address always seems to be changing
but we don't know what Halo2.exe is (CheatEngine does obviously) and we don't know how to code that.
Bitterbanana have me C++ reference which he didn't explain any further since he said VB.NET is a waste of time and I should upgrade.
Well I guess this is as good as it gets.
So far all I know is that there is like minimal memory protection, and client based memory hacks, such as speed hacks sync online... :/
jahrain is right, there doesnt seem to be any restrictions on editing memory. although vb isnt too great but i think 2005 works fine.
so yah as me and pat dont have vista/game not much has been attempted really.
The server app I was working on is kinda put on hold, it's kinda problematic if you want to leave your computer unattended, and I dont know how to fix the problems I encounter. I'm just a noob programmer, and there's a lot of things that need to be done still.
So you have to babysit the app?
Also, kornman is delete-o-topic happy :D
yeah, pretty much.Quote:
Originally Posted by Limited
I might be of some assistance here.
First off, executable files on Win32 are named Portable Executables.
Try googling Portable Executable format, it'll yield plenty of information.
Second, the process EXE is always loaded to what is referred to as it's ImageBase (defaults to 0x400000 with most tools but it can be overridden).
This happens because it's practically the first module to be mapped into the process address space.
And second because EXE's do not carry the extra information needed to relocate it.
With DLL's the Imagebase is only a hint of preference.
If a DLL can be mapped to it's ImageBase it will be.
Otherwise it will have to be relocated to some other address.
That being said, if all you wan't to do is determine the start address and size of the EXE in memory, then there's a pretty convenient API.
CreateToolhelp32Snapshot, Module32First & Module32Next will provide you with that information.
The first module entry returned belongs to the process EXE.
As for modifying the memory, I'm sure you know of Read/WriteProcessMemory.
EDIT:
I should probably clarify what an virtual address is.
In PE terminology there's Physical, Virtual and Relative addresses.
Physical refers to the file address/offset.
Virtual refers to the memory address.
Relative refers to an offset in memory, based from the ImageBase.
So, a VirtualAddress within an image is: ImageBase+RelativeAddress.
The distinction between Physical and Relative is important because PE files are not simply copied into memory.
But rather they're mapped according to their section table (PE files are split into various memory sections, which must be aligned).
In other words, there isn't a one to one relationship between what you see in a file and what's in memory.
That is what we have the reference for in C++ I do believe but we can't find any references for visual basic.Quote:
Originally Posted by abcba
I've never used VB beyond VBS.
But this should at least give you a point of reference.