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@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@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
