Please see the back trace below, I don´t think I have seen this before and I can not find any information in the documentation:
(gdb) bt
#0 0x000000007b44042c in Driver::setRec (this=0x1, message=#0x50)
I can't find it in documentation, but it looks like this is how gdb displays references to variables. According to backtrace, you were stopped at class method, accepting 1 parameter by reference with the following signature: Driver::setRec(message&).
Update:
It is not explicitly stated about # in C++ Expressions documentation. The only thing stated is:
In the parameter list shown when gdb displays a frame, the values of
reference variables are not displayed (unlike other variables); this
avoids clutter, since references are often used for large structures.
The address of a reference variable is always shown, unless you have
specified `set print address off'.
I dont know if this helps but from http://sources.redhat.com/gdb/download/onlinedocs/gdb.html#index-g_t_0040_0040_0040r_007b_002c-referencing-memory-as-an-array_007d-525
It is often useful to print out several successive objects of the same type in memory; a section of an array, or an array of dynamically determined size for which only a pointer exists in the program.
You can do this by referring to a contiguous span of memory as an artificial array, using the binary operator #'. The left operand of #' should be the first element of the desired array and be an individual object. The right operand should be the desired length of the array. The result is an array value whose elements are all of the type of the left argument. The first element is actually the left argument; the second element comes from bytes of memory immediately following those that hold the first element, and so on. Here is an example. If a program says
There for how I would interet this is 0x50 is a pointer address to the beginning of a string where the output message is. If I find more information on this I will update the post.
its for printing successive memory locations as array like output.
$gdb *memory#10
${1,2,3,4,5,6,7,8,9,10}
its a less powerful but easy to use memory inspection. if you want more power you should use the x (examine memory) command. consult
$info gdb
Related
I'm trying to figure out how I could make a linked list which links to a single byte array. So each element I put into the byte array could be enqued() and dequeued(). However, I need to figure out how to do this using pointer offsets and linked lists.
My question is:
How do I get an offset of a set amount from the start of a pointer? For example, let's say the beginning of my list is at one pointer. I would start by just checking if that space is empty, if not, get the next value in the list. How do I offset from a current pointer position and get a new pointer location that is basically just an offset of another pointer, forward or backwards, up or down, left and right, plus or minus.
Someone asked for an example:
byte myData[1024];
I have to store all of my data into this. This is for a class assignment. Essentially, I have to use this array to store any and all of my data to it, and basically create a queue, like the standard c++ queue. I have to create Enqueue() and Dequeue() functions and then dynamically allocate the memory for each. I have a general idea of what I'm doing. I'm stuck on trying to figure out how to take a pointer of my current position, and then set it to a new position, and then have that be my "next" in the list.
It sounds like what you really want is pointer arithmetic. It's simple enough.
std::int32_t foo[] = {42, 350};
std::int32_t* intPtr = &foo; // We'll say foo is at address 0x005
++intPtr; // Or intPtr += 1, either way the value of intPtr is now 0x009
// *intPtr would now give you 350.
// Your program knows the type being pointed to, and bumps up the address
// accordingly. In this case a 4-byte integer
When doing pointer arithmetic on a C-array, it's important to have checks in place to stop you going out of bounds on either side. However, I don't even think pointer arithmetic is necessary. If you're storing an array privately, simply using index access and tracking what index your list ends at is a lot simpler. You still have to do checks, but their easier checks.
You're also saying linked list, but describing an array list. They are two very different data structures. Your queue will be a lot easier to write if you write a separate array list class, and store an array list object in your queue instead or a raw array.
How do I get an offset of a set amount from the start of a pointer?
Read the C++11 standard n3337 about pointer arithmetic. Notice the existence of offsetof in C++.
If you have two short*ptr1; and short*ptr2; pointers which contain a valid address, you might code ptr1 - ptr2 or ptr1 + 5 or ptr2 - 3 (however, ptr1+ptr2 is forbidden). The C++11 standard explains when that is valid (sometimes it is not, e.g. when ptr2 is the nullptr). Notice also that in general &ptr1[3] is the same as ptr1+3 and ptr2[-1] is exactly *(ptr2-1) (when that makes sense).
Beware of undefined behavior in your code, such as buffer overflows (and you will have one if you do pointer arithmetic carelessly: beware of segmentation faults).
Tools like address sanitizers, debuggers (such as GDB), valgrind should be helpful to understand the behavior of your code.
Don't forget to enable warnings and debug info in your C++ compiler. Once your C++ code compiles without warnings, read how to debug small programs. With GCC, compile with g++ -Wall -Wextra -g. Notice that GCC 10 adds some static analysis abilities. And you could use the Clang static analyzer or Frama-C (or develop your own GCC plugin).
The linked list wikipage has a nice figure. The wikipage on tries could help you also.
I recommend reading a good C++ programming book and then some introduction to algorithms.
On github or elsewhere you can find tons of examples of C++ code related to your question (whose terminology is confusing to non-native English speakers).
Academic papers about memory shape analysis (such as this one or that one) contain figures which would improve your understanding. Books or web resources about garbage collection are also relevant.
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.
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.
I'm currently making one of those game trainers as a small project. I've already ran into a problem; when you "go into a different level", the addresses for things such as fuel, cash, bullets, their addresses change. This would also happen say, if you were to restart the application.
How can I re-locate these addresses?
I feel like it's a fairly basic question, but it's one of those "it is or is not possible" questions to me. Should I just stop looking and forget the concept entirely? "Too hard?"
It's a bit hard to describe exactly how to do this since it heavily dependents on the program you're studying and whether the author went out if his way to make your life difficult. Note that I've only done this once but it worked reasonably well even if I only knew a little assembly.
What is probably happening is that the values are allocated on the heap using a call to malloc/new and everytime you change level they are cleaned up and re-allocated somewhere else. So the idea is to look at the assembly code of the program to find where the pointer returned by malloc is stored and figure out a way to reliably read the content of the pointer and find the value you're looking for.
First thing you'll want is a debugger like OllyDbg and a basic knowledge of assembly. After that, start by setting a read and write breakpoint on the variable you want to examine. Since you said that you can't tell exactly where the variable is, you'll have to pause the process while it's running and search the program's memory for the value. Hopefully you'll end up with only a few results to sift through but be suspicious of anything that is on the stack since it might just be a copy for a function call or for local use.
Once the breakpoint is set just run the program until a break occurs. Now all you have to do is look at the code and examine how the variable is being accessed. If it's being passed as a parameter, go examine the call site of the function. If it's being accessed through a pointer, make a note of it and start examining the pointer. If it's being accessed as an offset of a pointer, that means it's part of a data structure so make a note of it and start examining the other variable. And so on.
Stay focused on your variable and just keep examining the code until you eventually find the root which can be one of two things:
A global variable that has a static address. This is the easiest scenario since you have a static address hardcoded straight into the code that you can use to reliably walk through the data structures.
A stack allocated variable. This is trickier and I'm not entirely sure how to deal with this scenario reliably. It's possible that its address will have the same offset from the beginning of the stack most of the time but it might not. You could also walk the stack to find the corresponding function and its parameters but this a bit tricky to get right.
Once you have an address all that's left to do is use ReadProcessMemory to locate your variable using the information you found. For example, if the address you have represents a pointer to a data structure where at offset 0x40 your fuel value is stored, then you'll have to read the value at the address, add 0x40 to it and do another read on the result.
Note that the address is only valid as long as the executable doesn't change in any way. If it's recompiled or patched then you have to start over. I believe you'll also have to be careful about Windows' ASLR which might change the address around every time you start the program.
Comment box was too small to fit this so I'll put it here.
If it's esp plus a constant then I believe that this is a parameter and not a local variable (do confirm by checking the layout of the calling convention). If that's the case, then you should step the program until it returns to its caller, figure out how the parameter is being set (look for push instructions before the call instruction) and continue exploring from there. When I did this I had to unwind the stack once or twice before I found the global pointer to the data structure.
Also the esi register is not related to the stack (I had to look it up) so I'd check how it's being set. It could be that it contains the address of the data structure and the constant is the offset to the variable. If you figure out how the register is set you'll be that much closer to the pointer.
EDIT: I have found the error: I did not initialize an array with a size. question can be closed.
I have a class V, and another class N. An object of N will have an array of pointers to objects of class V (say V **vList). So, N has a function like
V **getList();
Now in some function of other classes or simply a driver function, if I say V **theList = (N)n.getList(); Q1: theList would be pointing at the 1st element of the array? Given that the size of array is known, can I loop through with index i and say V *oneV = *vList[i]? Please correct me if what I'm doing above is wrong.
I have been using debugger to trace through the whole process of my program running, the thing I found was that after using V *oneV = vList[i], the value of the pointers in the array, vList, were the same as when they were created, but if I follow the pointer to where it is pointing at, the object was gone. I'm guessing that might be the reason why I am getting seg fault or bus error. Could it be the case? WHY did I 'loose' the object at the other end of a pointer? What did I do wrong?
and yes, I am working on a school assignment, that's why I do not want to print out my codes, I want to finish it myself, but I need help finding a problem. I think I still need explanation on array of pointers. Thank you
Q1 is right. For the second part, V *oneV = vList[i] would be the correct syntax. In your syntax you are dereferencing one more time (treating an object of type V as a pointer to such an object) which obviously is crashing your code.
EDIT:
Since you are using the correct syntax, the reason of segfaults would depend on your memory management of the objects of type V. If you have inserted addresses of objects created on the stack (automatic vars, not by new or malloc) inside a function and are trying to access them outside of it, then the pointers would be dangling and your code will crash.
Class N has to manage the number of elements in a list somehow. The usual approaches are to make a public function which returns the number of elements in the array, or to provide an iterator function which loops over all the list's elements.
An array with N elements are stored at array[0] through array[N-1]. You're accessing one past the end of the array.
First rule out the initial ones:
you are initializing correctly (new instead of automatic/local variables)
you are accessing the elements correctly (not like in the typo you posted in the question - based on your comment)
you are using the right size
If you go through all the normal ones and everything is k, then make sure to pay special attention to your loops / size calculations / and anything else that could be causing you to write to unintended addresses.
It is possible to write garbage at unintended locations & then get the error in unexpected places ... the worst I saw like that, was some file descriptors's variables being corrupted because of an array gone wrong right before those variables - it broke on file related functions, which seemed v. crazy.
theList would be pointing at the 1st
element of the array? Given that the
size of array is known, can I loop
through with index i and say V *oneV =
*vList[i]?
Yes, that is correct.
I'm guessing that might be the reason
why I am getting seg fault or bus
error. Could it be the case?
Yes, if you have an invalid pointer and try to dereference it you'll get a segfault.
WHY did I 'loose' the object at the
other end of a pointer? What did I do
wrong?
That is difficult to predict without seeing the actual code. Most probable causes are that either you are not filling the V** correctly or after putting a V* pointer inside V** array you are deleting that object from some other place. BTW, I am assuming that you are allocating memory using new, is this assumption correct?