[Tutor] Windows Memory Basics

Michael C mysecretrobotfactory at gmail.com
Mon Oct 16 19:53:39 EDT 2017

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>

> 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

More information about the Tutor mailing list