CODEWITHSUNDEEP
c++linuxdebugginggdbheap
seenmycorpseanywhere
seenmycorpseanywhere

Reputation: 768

gdb: get references to value returned by the find command

I'm trying to port a program I wrote in windows with syscalls to linux. The program reads the memory of another running process and displays certain values as they change. To get started and figure out how I'll do it, I decided to do a proof of concept in the shell.

The first thing I did was check the mapped memory:

cat /proc/105928/maps > maps

And from that output I find the heap:

555558ed2000-55555ed43000 rw-p 00000000 00:00 0 [heap]

Now, because I know a few things about the examined executable, I know somewhere in there there's an array of objects, and some of them have the value 95000 (integer, 4 bytes) in a certain field. So with gdb it's quite easy to find references to these values, and sure enough, there are 4 of them:

(gdb) find 0x555558ed2000, 0x55555ed43000, 95000
0x55555c3f0744
0x55555deb7f50
0x55555deb8b60
0x55555deb9800

I do not have access to debug symbols, but what I do have is a reference that tells me the offset of the field with the value of 95000. It's 0x570, so subtracting it from any of the matches (let's take the first one) gives me the address of the object.

0x55555c3f0744 - 0x570 = 0x55555c3f01d4

Since it's a dynamic array, there must be somewhere in memory which holds that value as a pointer, and that I'm interested in finding. I've tried a few things, mostly variations of this, which searches in the heap for said value, but I haven't quite managed it (the /g modifier is needed, I assume, because pointers are 8 bytes):

(gdb) find /g 0x555558ed2000, 0x55555ed43000 - 0x8, 0x55555c3f01d4
Pattern not found.

Something is tripping me and I don't know what. What could be wrong here? Is something wrong with my reasoning?

Upvotes: 4

Views: 70

Answers (1)

Atsushi Yokoyama
Atsushi Yokoyama

Reputation: 81

Generally, the object code generated by the compiler is highly optimized. So even if an offset to a certain address is 0x570 away from the "base address," it does not necessarily mean that the object generated by the compiler or the dynamically created memory image at runtime actually contains the "base address" 0x55555c3f01d4, which is 0x570 subtracted from the found address.

If possible, try generating an assembly source when compiling the target executable and search through the assembly source. If you can find the assembly code handling the dynamic array you are looking for, reading it might provide useful insights.

Hope this helps!

Upvotes: 1

Related Questions