Pointer To A String

[Iain]

I'd like to be able to retrieve the address of a string, but am finding it confusing. Here's the code that I'm using:

//Compile using <g++ hak5.cpp -o hak5.exe>
#include <stdio.h>

int main()
{
	char * Pointer_to_First_String = "hello";
	char * Pointer_to_Second_String = "HELLO";
	char amessage[] = "hello, world";

	printf ("\nPointer to first string\t\t= 0x%08x\n", Pointer_to_First_String);
	printf ("Pointer to second string\t= 0x%08x\n", Pointer_to_Second_String);	

	printf("\nThe value of amessage is \t= 0x%08x\n", amessage);
	printf("The value of *amessage (hex) is = 0x%08x\n", *amessage);
	printf("The value of *amessage (dec) is = %d\n", *amessage);

	printf("\namessage is:\t\t\t  %s\n", amessage);
	amessage[0] = 'H';
	amessage[7] = 'W';
	printf("amessage has been changed to:\t  %s\n", amessage);

	return 0;
}

The code compiles fine and returns the addresses of the first two strings (as confirmed by examining the .rdata section in OllyDbg) but the address returned for the final string is 0x0022ff2b. However, when I review the .rdata section in OllyDbg, the address of this final string is actually 0x0040316c.

Is it possible to return this value programmatically? It seems that 0x0022ff2b is the stack of the main thread and I realise that this changes as the program runs.

Thanks in advance.

[Jason Cooper]

Yes it is pointing to the stack, but the good news it that is where the string it is pointing to is located.

When the function is called it creates two pointers that it then sets to point to a constant string (hence them pointing into the .rdata section. It then creates a pointer that points to a char array. The char array is a variable, not a constant, so it has to create the char array on the stack. Once it has created the char array it can set the pointer to point to it.

[Iain]

Thank you Jason.

So, if I want to print the address of the location of the string in the .rdata section from within the program (rather than obtain it using OllyDbg), how would I do that? From what you said, it's the address of the char array. I can obtain the address of the stack location but that's not what I want.

[Jason Cooper]

You would most likely have to resort to defining you local char array and then manually copy the string from constant into the char array, then you would be able to get the address of the constant and the location of the char array. This is messy though and a waste of your time unless you have a very good reason you require the address of the constant used to populate your char array.

You also open yourself up to horrible problems if you change the length of your constant but don't update the size of your char array as you could overwrite parts of your stack (of course you would use strncpy and not strcpy to avoid this).

[Iain]

Hmm Jason - that's an interesting idea. I didn't think about copying the string from one to the other. At the moment, it's really an academic exercise. I started reading about pointers, * and & and just didn't understand why it's so easy to determine the address of a string if it's defined in one way but impossible to derive it programmatically if it's defined in another way.

An alternative that I thought about (and still have to investigate) is to step through the code using OllyDbg (or similar). I've seen the actual address of the string in a register when defined as char[] so I thought about having some inline assembly to pull the value of the register and deliver it to a variable (outside the inline assembly) that could be printed using printf or used elsewhere in the code.

[pngwen]

One small thing before I start. I am a teacher of coders, particularly in the ways of C, Computer Architecture, and Theoretical Computer Science. I am in a weird sort of guru mode tonight, so I will tell you a story, one which will make plain the ways of memory.

Gather round my young nerdlings, and attend my tale. In the days of the before time, the long long ago, machines ran but one program at a time. These machines were usually directly coded in their pure languages. The humans did move things in and out of memory, and all was well. But then, more people wanted to command these magical boxes, and there were not enough of these boxes to go around, and so the idea of time sharing was born. First, the idea was simple. "Let us write monitors" the gurus of that day said. "They will manage memory, and give slices to processes. One shall execute and once, and they shall not cross the boundaries of another." But alas, this did not appease the crowds, another way had to be found.

"Let us rapidly switch from one running task to another." One of the gurus said. "But how can we do that? Yay, verily the process of ones own brother would utterly blorch the memory of ours." and then they spake saying "Let us not concern ourselves with the true memory. We shall hide it behind a magical wall, one which will manage memory. Let it's name be called MMU, for that is the unit which manages the memory. It shall move memory in pages, and physical addresses will become as transitory as we are." and the people did see that their process could all live in piece, thinking that each had complete access to the machine on its own, and the MMU did keep their segments apart. The processes could be located anywhere in memory. Memory could be disjoint, and well used, and everyone was very pleased for it was very good. That is why you cannot get the physical address from the pointer, for the pointer is not wise. The pointer sees only the illusion of its self. You must go higher, and ask the OS for the true address. BUT! Be cautious young programmers, for once thou knowest the true memory location, there is no guarantee that the memory shall reside there the next time. Pages swap. Physical addresses are no more constant than lotus blossoms floating on a river.

When the master thus spake to his students, they asked of him,

Students: "But how can we know the truth if not even the pointers know?"

Guru: "You must reach out to the OS, and make a call to its API to find it."

Students: "How shall we call it?"

Guru: "Well, it depends upon the OS. You mentioned Olly DBG, so I assume you are running on the Redmond attrocity. Seek you out documentation on the MmGetPhysicalAddress function. Seek you out its breatheren, the other redmond calls which begin Mm, and you can truly pwneth they boxen!"

Students: "What of the unixes? Do they know their memory address"

Guru: "But of course, you must simply ask the kernel."

Students: "But how shall we call it?"

Guru: "Read the source my younglings. The answer you seek lies within there. You need naught but your own eyes and patience to know all that there is of unixes. Now go! Look up those functions, read the memory mapping code, and become enlightened. Our time is brief, soon we shall page out of this world, into a most corruptible swap. Now meditate on the transitory nature of all things."