We're heading into advanced territory here and I might get told off but...
Consider this C++ program for a second, it has a struct with different
types of variables which sit next to each other in memory. When you print
the byte values of the struct, you can see that there is no easy way to
know which byte value belongs to which variable unless you already know the
layout.
-----------------
#include <stdio.h>
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
#pragma pack(1)
struct mem
{
char c; // 1 byte
WORD wn; // 2 byte
DWORD dwn; // 4 byte
int i; // 4 byte
BYTE b; // 1 byte
};
int main()
{
mem s;
s.c = 0xFF;
s.wn = 0xFFFFF;
s.dwn = 0xFFFFFFFF;
s.i = 0xFFFFFFFF;
s.b = 0xFF;
BYTE * memPointer = reinterpret_cast<BYTE *>(&s);
for (int i = 0; i < sizeof(mem); i++)
printf("%02d [0x%08x] = %x \n", i, memPointer, *memPointer++);
return 0;
}
---------------------
Prints
00 [0xecf0f789] = ff
01 [0xecf0f78a] = ff
02 [0xecf0f78b] = ff
03 [0xecf0f78c] = ff
04 [0xecf0f78d] = ff
05 [0xecf0f78e] = ff
06 [0xecf0f78f] = ff
07 [0xecf0f790] = ff
08 [0xecf0f791] = ff
09 [0xecf0f792] = ff
10 [0xecf0f793] = ff
11 [0xecf0f794] = ff
Packing can also come into play. If you change the packing to 2, you get
this:
00 [0x7d4ffcd9] = ff
01 [0x7d4ffcda] = cc
02 [0x7d4ffcdb] = ff
03 [0x7d4ffcdc] = ff
04 [0x7d4ffcdd] = ff
05 [0x7d4ffcde] = ff
06 [0x7d4ffcdf] = ff
07 [0x7d4ffce0] = ff
08 [0x7d4ffce1] = ff
09 [0x7d4ffce2] = ff
10 [0x7d4ffce3] = ff
11 [0x7d4ffce4] = ff
12 [0x7d4ffce5] = ff
13 [0x7d4ffce6] = cc
And if you change it to 4, you get this:
00 [0xf4f5fbf9] = ff
01 [0xf4f5fbfa] = cc
02 [0xf4f5fbfb] = ff
03 [0xf4f5fbfc] = ff
04 [0xf4f5fbfd] = ff
05 [0xf4f5fbfe] = ff
06 [0xf4f5fbff] = ff
07 [0xf4f5fc00] = ff
08 [0xf4f5fc01] = ff
09 [0xf4f5fc02] = ff
10 [0xf4f5fc03] = ff
11 [0xf4f5fc04] = ff
12 [0xf4f5fc05] = ff
13 [0xf4f5fc06] = cc
14 [0xf4f5fc07] = cc
15 [0xf4f5fc08] = cc
In other words, even if you have the source code for the program you want
to scan in memory, depending on the compiler settings the memory layout
could have changed, or rather not be what you expected due to packing and
alignment.
Probably not the answer you were hoping for but I hope this helps.
--
James
On 17 October 2017 at 01:02, Michael C <mysecretrobotfact...@gmail.com>
wrote:
> Hold on, supposed by using Openprocess and VirtualQueryEx, I have the
> locations of all the memory the application is using, wouldn't this to be
> true?
>
> Say, a 8 byte data is somewhere in the region i am scanning. Ok, I know by
> scanning it like this
> for n in range(start,end,1)
>
> will read into another variable and mostly nothing, but unless a variable,
> that is, one number, can be truncated and exist in multiple locations like
> this
>
> double = 12345678
>
> 123 is at x001
> 45 is at x005
> 678 is at x010
>
> unless a number can be broken up like that, wouldn't I, while use the silly
> 'increment by one' approach, actually luck out and get that value in it's
> actual position?
>
>
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
