[Tutor] Windows Memory Basics

[Michael C]

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?




On Mon, Oct 16, 2017 at 4:53 PM, Michael C <mysecretrobotfactory at gmail.com>
wrote:

> ah, i am bummed completely haha.
>
> Is there a way to tell which parts a variables so I can scan it?
> Maybe you could point me to some reading materials?
>
> thanks :)
>
> On Mon, Oct 16, 2017 at 4:48 PM, Alan Gauld via Tutor <tutor at python.org>
> wrote:
>
>> On 16/10/17 21:04, Michael C wrote:
>>
>> > I don't understand this part about the memory:
>>
>> And I'm not sure I understand your question but...
>>
>> > if I used VirtualQueryEx to find out if a region of memory is ok to
>> scan,
>> > and it
>> > says it's ok, are the values in the region arranged like this:
>> >
>> > short,int,double,long,char, double, short in
>> >
>> > as in, random?
>>
>> They won't be random, they'll be in the order that the
>> program that wrote the memory chose them to be in. For
>> example the memory might contain some program variables
>> and those variables may be of different types (assuming
>> a compiled language like C++, say). Or it may be holding
>> a complex data structure, like a class, that has fields
>> of different types.
>>
>> What those types are will not be obvious and unless you
>> know what you are reading will be impossible to guess
>> in most cases since it is just a sequence of bytes and
>> one set of 8 bits looks a lot like any other.
>>
>> > I am asking this because, if it's random, then I'd have to run
>> > ReadProcessMemory
>> >  by increasing  the value of of my loop by ONE (1) at a time, like this
>>
>> That doesn't really help, you need to know what each
>> chunk of data represents and then increment the index
>> by the size of each corresponding data type.
>>
>> For example if you have a string of 8 UTF8 characters
>> that will probably be 8 bytes long(some UTF characters
>> are more than 8 bits). But those 8 bytes could equally
>> be a floating point number or a long integer or a
>> struct containing 2 32 bit ints. You have absolutely
>> no way to tell.
>>
>> And if you increment your index by one you will then
>> look at the first 7 bytes plus one other. What is
>> the 8th byte? It could be the start of another float,
>> another UTF8 character or something else entirely.
>>
>> Things are then further complicated by the tendency
>> to store data on word boundaries, so either 4 or
>> 8 byte chunks, but even that can't be guaranteed
>> since it could be a compressed memory scheme in
>> action or a piece of assembler code taking the
>> 'law' into its own hands.
>>
>> And of course it may not represent anything since
>> many programs set aside memory spaqce for later use
>> and either fill it with zeros or some other arbitrary
>> pattern, or just leave it with whatever bits happened
>> to already be there.
>>
>> > for i in range(start_of_region, end_of_region, 1):
>> >       ReadProcessMemory(Process, i, ctypes.byref(buffer),
>> > ctypes.sizeof(buffer),             ctypes.byref(nread))
>> >
>> > Is that correct?
>>
>> Probably not. If you know what data you are reading you
>> can do what you want, but if it's just a random block
>> of memory you are scanning then its almost impossible
>> to determine for certain what the raw data represents.
>>
>> If you have access to a *nix system (or cygwin
>> on windows) it may help you to see the nature
>> of the problem by running od -x on a text file
>> You can find out what is in it by looking at it
>> in a text editor but the hex listing will be
>> meaningless. If that's what simple text looks
>> like imagine what a binary file containing
>> mixed data is like.
>>
>> --
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
>> _______________________________________________
>> Tutor maillist  -  Tutor at python.org
>> To unsubscribe or change subscription options:
>> https://mail.python.org/mailman/listinfo/tutor
>>
>
>