I am trying to view a structure passed as argument to my function.. However while debugging in Trace32 it is only showing me the start address of the structure, but not complete strucute. I can see the values in memory dump at that location, but i want to format the memory location with my structure type, to visualize the values of each data members. Can i do that ?
I guess the command you are looking for is Var.View (or Var.Watch).
E.g.
Var.View %Open (struct mystruct_s *)0x00007890
The Dump.* commands deal with raw memory. Any symbol used with those are considered just as an address.
The Var.* commands deal with high level language expressions, which basically means C/C++ syntax, which also considers C/C++ data types.
Related
I've been trying to wrap my head around how C/C++ code is represented in machine code and I'm having trouble understanding what data types actually are apart from a designation of memory length.
Types also are associated with;
a set of values that all variables of that type can represent;
the layout in memory of that type (e.g. the meaning, if any, attached to each bit or byte that represents a variable),
the set of operations that can act on a variable;
the behaviour of those operations.
Types are not necessarily represented directly in machine code. A compiler emits a set of instructions and data (in a way that varies between target platforms) that manipulate memory and machine registers. The type of each variable, in C source, gives information to the compiler about what memory to allocate for it, and the compiler makes decisions for mapping between expressions (in C statements) and usage of registers and machine instructions to give the required effects.
Stash library in "Thinking in C++" by Bruce Eckel:
Basically he seems to be setting up an array-index-addressable interface (via fetch) to a set of entities that are actually stored at random memory locations, without actually copying those data entities, in order to simulate for the user the existence of an actual contiguous-memory data block. In short, a contiguous, indexed address map. Do I have this right? Also, his mapping is on a byte-by-byte basis; if it were not for this requirement (and I am unsure of its importance), I believe that there may be simpler ways to generate such a data structure in C++. I looked into memcpy, but do not see how to actually copy data on a byte-by-byte basis to create such an indexed structure.
Prior posting:
This library appears to create a pointer assemblage, not a data-storage assemblage.
Is this true? (Applies to both the C and C++ versions.) Thus the name "stash" might be a little misleading, as nothing but pointers to data stashed elsewhere is put into a "stash," and Eckel states that "the data is copied."
Background: Looking at “add” and “inflate,” the so-called “copying” is equating pointers to other pointers (“storage” to “e” in “add” and “b” to “storage” in “inflate”). The use of “new” in this case is strange to me, because storage for data is indeed allocated but “b” is set to the address of the data, and no data assignments seem to take place in the entire library. So I am not sure what the point of the “allocation” by “new” is when the allocated space is apparently never written into or read from in the library. The “element” to be added exists elsewhere in memory already, and seemingly all we are doing is creating a sequential pointer structure to each byte of every “element” desired to be reference-able through CStash. Do I understand this library correctly?
Similarly, it looks as though “stack” in the section “Nested structures” appears actually to work only with addresses of data, not with data. I wrote my own linked-list stack successfully, which actually stores data in the stack nodes.
I'm trying to make a program that can read some information from another process. I use Cheat Engine to find the memory address of whatever I'm looking for and ReadProcessMemory in c++ to get the value.
So far so good. Here is my problem: The process I'm trying to get the information from can have multiples windows open at the same time. I will take notepad++ as an example. With notepad++, I can open as many .txt files as I want. Each of these files' content will have their own memory address. So what I think I need is a memory address with every pointer to every files content as value
Example:
Address A = Value 1
Address B = Value 2
Address C = Value 3
etc... for all files opened
I would need to find a static address with the value: (address A, address B, address C, etc...).
I don't even know how to look for that... Can a memory address hold an array of values...?
EDIT: Really guys, you think the ONLY purpose of cheat engine is cheating? I'm not trying to cheat or hack anything. I didn't know trying to learn about memory address was wrong... For your info, I'm trying to make my own interface for a program I like. AN INTERFACE, that's not cheating.
In a program where windows are dynamically allocated, variables related to those windows will generally be dynamically allocated as well. That means the addresses may be different each time the program runs (depending on what else is in the program's heap at the time). In order to reliably get those locations, you'd need to start at the top-level static pointer (e.g. the address of the list of windows) and then dynamically follow the chain of dynamically-allocated pointers down to the addresses you are looking for. Whether CheatEngine can do this, or if it can even be done safely at all, I don't know.
Memory only holds numbers. It may be helpful to think of process memory as a huge list of numbers, each taking a value in the range (0-255). How those numbers are interpreted as is entirely up to the process (i.e., notepad in your example). This includes whether or not they are some "value" or perhaps a pointer to some value, etc.
My guess is that data is scattered in physical memory (even the data of a class object is sequential in virtual memory), so in order to send the data correctly it needs to be reassembled, and to be able to send over the network, one additional step is the transformation of host byte order to network byte order. Is it correct?
Proper serialization can be used to send data to arbitrary systems, that might not work under the same architecture as the source host.
Even an object that only consist of native types can be troublesome sharing between two systems because of the extra padding that might exists in between and after members, among other things. Sharing raw memory dumps of objects between programs compiled for the same architecture but with different compiler versions can also turn into a big hassle. There is no guarantee how variable type T actually is stored in memory.
If you are not working with pointers (references included), and the data is meant to be read by the same binary as it's dumped from, it's usually safe just to dump a raw struct to disk, but when sending data to another host.. drum roll serialization is the way to go.
I've heard developers talking about ntohl / htonl / ntohl / ntohs as methods of serializing/deserializing integers, and when you think about it saying that isn't that far from the truth.
The word "serialization" is often used to describe this "complicated method of storing data in a generic way", but then again; your first programming assignment where you were asked to save information about Dogs to file (hopefully*) made use of serialization, in some way or another.
* "hopefully" meaning that you didn't dump the raw memory representation of your Dog object to disk
Pointers!
If you've allocated memory on the heap you'll just end up with a serialised pointer pointing to an arbitrary area of memory. If you just have a few ints and chars then yes you can just write it out directly to a file, but that then becomes platform dependent because of the byte ordering that you mentioned.
Pointer and data pack(data align)
If you memcpy your object's memory, there is dangerous to copy a wild pointer value instead of it's data. There is another risk, if the sender and receiver have different data pack(data align) method, you will get rubbish after decoding.
Binary representations may be different between different architectures, compilers and even different versions of the same compiler. There's no guarantee that what system A sees as a signed integer will be seen as the same on system B. Byte ordering, word langths, struct padding etc will become hard to debug problems if you don't properly define the protocol or file format for exchanging the data.
Class (when we speak of C++) also includes virtual method pointers - and they must be reconstructed on receiving end.
I'm creating my first real binary parser (a tiff reader) and have a question regarding how to allocate memory. I want to create a struct within my TiffSpec class for the IFD entries. These entries will always be 12 bytes, but depending upon the type specified in that particular entry, the values at the end could be of different types (or maybe just an address to another location in the file). What would be the best way to go about casting this sort of data? The smallest size memory I believe I would be dealing with would be 1 byte.
In C++ you should use a union.
This is a mechanism by which you can define several, overlapping data types, possibly with a common header.
See this article for how to use unions for exactly your problem -- a common header with different data underneath.