I am going to put your reply in a special place, for the day I can
understand it :)
On Tue, Oct 17, 2017 at 2:37 AM, James Chapman <ja...@uplinkzero.com> wrote:
> 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
