VB5: Working with memory
I need example source on how to search the systems ram for specific values, map out the entire contents of the systems ram, and alter values at any point within the systems ram. So for a simple example. Say program A which is a 3rd party app is running and has the value 20 stored in memory for it's own use. I need to be able to find that value and change it.
I'm not sure that this is possible. A General Protection Fault is what occurs when a program tries to access memory which is allocated to something outside it's own process.
There is a Windows API called GlobalMemoryStatus that can give you some info about memory, like how much is available etc. and you can see how this works through the VB Sample CallDLLs.
In general VB programs are prevented from scanning memory. There are no direct functions (PEEK and POKE are long gone) and the task encapsulation rules forbid programs from examining memory outside their designated task area.
Cross application memory access is dangerous and specifically forbidden. This will tend to destabilize windows (which is not known for it's rock solidity). I don't know what you're trying to do, but this approach is *NOT* going to work, or if you can get it to work will be so dangerous and unstable that it won't work in a production program.
Each task owns it's own memory space and can be rolled in and out of memory at any time. There is no guarentee that a specific task will remain in the same memory block from moment to moment.
The hardware memory management will generate a PAGE FAULT as soon as your task attempts to write to memory outside it's memory pool. This is so that one task cannot "corrupt" another. This is a core level protocol in the OS and should be breached.
Don't do this.
M
Cross application memory access is dangerous and specifically forbidden. This will tend to destabilize windows (which is not known for it's rock solidity). I don't know what you're trying to do, but this approach is *NOT* going to work, or if you can get it to work will be so dangerous and unstable that it won't work in a production program.
Each task owns it's own memory space and can be rolled in and out of memory at any time. There is no guarentee that a specific task will remain in the same memory block from moment to moment.
The hardware memory management will generate a PAGE FAULT as soon as your task attempts to write to memory outside it's memory pool. This is so that one task cannot "corrupt" another. This is a core level protocol in the OS and should be breached.
Don't do this.
M
Sorry s/b "should NOT be breached"...
M
M
![Avatar of Guy Hengel [angelIII / a3]](https://filedb.experts-exchange.com/files/public/2013/11/25/ddbe0ea6-aa6e-4279-b781-57b735dd3ea0.jpeg){kind=small}
I think our guy is trying to hack/bypass some password protected applications...
Agreeing on the comment of Mark2150 that memory allocation (pages) is volatile, you would need to
1) identify as system
2) lock the other application from running
3) scan and alter the memory
For all 3 of them, it is certainly possible, even within VB, to do this using some obscure and maybe undocumented API.
As Mark2150 proposed, i repeat you should really think, let's say 10 times, before you even try to implement something like this.
Could you present what/why you need this.
Agreeing on the comment of Mark2150 that memory allocation (pages) is volatile, you would need to
1) identify as system
2) lock the other application from running
3) scan and alter the memory
For all 3 of them, it is certainly possible, even within VB, to do this using some obscure and maybe undocumented API.
As Mark2150 proposed, i repeat you should really think, let's say 10 times, before you even try to implement something like this.
Could you present what/why you need this.
ASKER
No, I'm not trying to hack password protection schemes. If anything it's for me to learn more about how memory works and then hopefully spawn ideas from that to aid me in creating software to PREVENT what I'm wanting to do here. As is I know what I'm asking is very possible, because I've seen lots of apps that can do it. I need the inner workings to fully understand though.
ASKER
Start wth the obvious and most simplistic part that you CAN explain, then we'll expand from there. Example, I know data is stored at (practically random) intervals in memory...just filling the slots basically in the order that it is requested from each program. So program A and program B could have their data all mixed up in memory together. Well they both magically are able to pull that data back from memory. This means they have to be keeping track of what registers the data is stored in. Is there a "header" such as that in the beginning of file types used in memory blocks to distinguish between them? Provide some simple source so I can look at the contents of the memory on my system, not write to, just look. Then from there we'll expand this.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Good info for a start mark, but you didn't say where the "map" of the segement and offsets is being kept.
Simple example, 2 programs running.
0---------------20--------
| PROG A | PROG B |
Prog A was loaded into memory first, so it started at 0 and went till 20. Prog B was then loaded and goes to 40. Now lets say prog A needs more memory storage for a process. Which way does it handle it?
** EXAMPLE 1 **
0-------------30----------
| PROG A | PROG B
** EXAMPLE 2 **
0-------------20----------
| PROG A | PROG B | PROG A |
And then of course going back to, where is it storing this "map", or array or what have you, telling it that variable BLAH is stored in sector 45.
Lastly, you didn't really answer the initial question, just kinda went around it. Think of a game "trainer" for example. There are several out there which work with any game in existance because they scan the memory for the value you specify, then you change that value, it scans, then you change it again, it scans. By this run it knows exactly where the value is stored, and it can then be changed or frozen. I need to know specifically how to do this, as well as any theories on how to prevent it's use from a game producers stand point.
Simple example, 2 programs running.
0---------------20--------
| PROG A | PROG B |
Prog A was loaded into memory first, so it started at 0 and went till 20. Prog B was then loaded and goes to 40. Now lets say prog A needs more memory storage for a process. Which way does it handle it?
** EXAMPLE 1 **
0-------------30----------
| PROG A | PROG B
** EXAMPLE 2 **
0-------------20----------
| PROG A | PROG B | PROG A |
And then of course going back to, where is it storing this "map", or array or what have you, telling it that variable BLAH is stored in sector 45.
Lastly, you didn't really answer the initial question, just kinda went around it. Think of a game "trainer" for example. There are several out there which work with any game in existance because they scan the memory for the value you specify, then you change that value, it scans, then you change it again, it scans. By this run it knows exactly where the value is stored, and it can then be changed or frozen. I need to know specifically how to do this, as well as any theories on how to prevent it's use from a game producers stand point.
The MAP is kept in the memory management unit. It knows what it assigned to what task and where the boundaries are. This is the unit that throws the GPF when your task attempts to step "out of bounds". This is a hardware unit on the CPU address buss. It will stop your program in mid instruction with an interrupt and abort your task. When you reply to the "invalid page fault" or "General Protection error", the task is dumped from memory and processing (usually) continues.
In your example, Task B can be rolled out, additional memory allocated to task A and then task B brought back in again. This keeps all of task A contiguous and helps explain why your disk will sometimes chatter for no appearent reason.
The kind of memory access you're looking for is simply not part of VB. VB was designed *specifically* to hide the gory details of memory allocation to prevent tasks from interfering with one another. This is the classic definition of an "illbehaved" DOS app.
M
In your example, Task B can be rolled out, additional memory allocated to task A and then task B brought back in again. This keeps all of task A contiguous and helps explain why your disk will sometimes chatter for no appearent reason.
The kind of memory access you're looking for is simply not part of VB. VB was designed *specifically* to hide the gory details of memory allocation to prevent tasks from interfering with one another. This is the classic definition of an "illbehaved" DOS app.
M
ASKER
Using vb by itself I know it's impossible. But API routines or possible external dll's would make it very possible. The programs which CAN do this are written in VC++ 5...and win api and 3rd party dll's are typically written in c++.
ASKER