[Tutor] Windows Memory Basics

Michael C mysecretrobotfactory at gmail.com
Sat Oct 21 14:57:12 EDT 2017

cool stuff!

On Tue, Oct 17, 2017 at 2:17 AM, Alan Gauld via Tutor <tutor at python.org>

> On 17/10/17 01:02, Michael C wrote:
> > 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
> That won't happen, a single variable will always be in a a single
> area.
> But the representation won't be anything like you suggested. A
> single number 12345678(assuming its a decimal integer) will be
> stored as 0xbc614e, which is 3 bytes, so it will be part of
> a 4byte (assuming a 32bit integer) chunk of storage.
> Of course if the program declared the variable to be a long
> then the same 3 bytes will be stored within an 8 byte chunk.
> And if it was stored as a double floating point value then
> the byte representation will be entirely different (and
> I don't even know what that would be).
> > 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?
> Yes, if you know that the decimal number 12345678 is stored
> somewhere in memory, you can scan looking for the 3 bytes 0xbc,
> 0x61,0x4e. And if you also know it was stored in a 32 bit int
> you can check for zero before the first byte (or second, or last)
> depending on the endian storage system used by your OS).
> But you still don't know for sure that you didn't just find a
> byte of 0xbc followed by the start of a UTF8 string beginning
> with the characters 'aN'...  And there are likely to be several
> hits not just one. You need to figure out which are your number
> and which are just groups of 3 bytes that happen to look like it.
> If you are very clever you can look at the data surrounding
> each set of bytes and make a fair guess about ones which
> are not likely to be your variable (as above you might look
> to see if the following bytes are all viable ascii characters
> which might indicate that it was indeed a string and not
> your number). But that may still leave several candidates,
> and its all fraught with difficulty.
> If you do know the data types involved you can read your
> memory into a buffer and apply the struct module to
> interpret it (possibly in multiple ways) to extract
> the values but you must know the nature of what you are
> reading to be able to interpret it. ie. you need to know
> the types.
> Reading the bytes in memory is one thing, and relatively easy.
> Interpreting those bytes as actual data is nigh impossible
> unless you know in advance what data types you are looking at.
> --
> 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