[Tutorial] Advanced C (II)

[m0skit0]

<< Prev Next >>

Modifying a variable the tricky way

Ok so now that we know variables are stored into the stack, we can show some nasty ways of modifying function local variables from another function that (supposedly) knows nothing about that local variable.

Code: Select all

#include <stdio.h>

void trick(void)
{
	int* p;
	p = (int*)((int)&p + 0x28);
	*p = 12;
}

int main()
{
	int a = 10;
	trick();
	printf("%d\n", a);
	return 0;
}

If you compile and run this, you'll see it prints 12. How can this be when "a" is modified nowhere (at first look)? Well obviously we're somehow overwriting main()'s local variable in the trick() function. But, as far as we know, the trick() function has no way to know about main()'s "a" variable. Let's take a tour on how this works, focusing on the trick() function first.

Code: Select all

int* p;

This reserves space on the stack for the local "p" pointer, as we already know. But as we know too, main() uses the very same stack to store its own local variables. So the trick consists of knowing how far main()'s "a" variable is from trick()'s "p" variable. Let's see how we figure this using GDB

Code: Select all

$ gdb -q example01
Reading symbols from /home/m0skit0/Temp/example01...done.
(gdb) b 13
Breakpoint 1 at 0x80483ef: file example01.c, line 13.
(gdb) r
Starting program: /home/m0skit0/Temp/example01 

Breakpoint 1, main () at example01.c:13
13		trick();
(gdb) p &a
$1 = (int *) 0xbffff3ac

Here we got main()'s "a" address.

Code: Select all

(gdb) b 6
Breakpoint 2 at 0x80483ca: file example01.c, line 6.
(gdb) c
Continuing.

Breakpoint 2, trick () at example01.c:6
6		p = (int*)((int)&p + 0x28);
(gdb) p &p
$2 = (int **) 0xbffff384

Now we got trick()'s "p" address. We calculate the offset between both variables.

Code: Select all

(gdb) p/x 0xbffff3ac - 0xbffff384
$3 = 0x28

Thus

Code: Select all

p = (int*)((int)&p + 0x28);

Makes trick()'s "p" point to main()'s "a".

Code: Select all

*p = 12;

Assigns 12 to the address pointed by p, which is main()'s "a". When trick() function returns to main(), and main() gives printf() function the address of "a", it turns out there's a 12 value there, and that what's printed.

<< Prev Next >>

Advertising

[Lord Aaron]

the magic of pointers, not much else here

Advertising

[m0skit0]

Absolutely, pointers are awesome, although bitchy. And magic is not much else? Then I don't know what is something

Most people never get how to use pointers this way, and this way is needed to write stuff like HBL and other hacks. So it's useful to open people's mind so they can see other stuff maybe I cannot see and we all share our knowledge. If you already knew this, then I'm so happy for you!

[Lord Aaron]

I agree pointers are kind of hard to understand for beginners, but you gotta thank C for it, they are a lot easier to understand in assembly (matter of fact I got used to pointers with assembly, not C). As for hacks and such, I know that, I even took a look at VHBL's source and even made some changes here and there, not a big thing as VHBL is pretty much done with (coding-wise).

[hgoel0974]

So true, I just wish there were a proper Vala IDE, it's like C# but native and pointers are allowed (without the unsafe stuff)
Pointers were hard to understand when I first heard of them, now that I understand them, they're an amazing tool!
Especially the ability to store a pointer to a variable so that other threads for example have a sort of 'local copy' of the variable which is updated as the original variable is.

[m0skit0]

but you gotta thank C for it

Of course, who said otherwise But sometimes you don't need to mess with this stuff, and then C/C++ is just an annoying language to fight against for the simplest task...

they are a lot easier to understand in assembly (matter of fact I got used to pointers with assembly, not C)

dang, same here. Well I was taught pointers in Pascal first, but never fully grasped the idea until I programmed in assembly. Assembly really gives you an insight of how a computer works that no other programming language can ever deliver. This is why assembly is awesome. For all other things, assembly sucks.

VHBL is pretty much done with (coding-wise).

Well IMHO HBL is a **** coding mess, it would surely benefit from a re-write, but meh, it does the dang job. This is something I guess happens to all programmers when you look at your old work, you're like "WTF this is horrible, how the heck did I write this ****". But I would never have thought it would be still be used like 5 years when I started writing it lol Community FTW!

Especially the ability to store a pointer to a variable so that other threads for example have a sort of 'local copy' of the variable which is updated as the original variable is.

I don't know much C# but I can do that in Java without pointers or any extra stuff. Although in the end, all variables are actually pointers... they just now call them "references" (like nowadays directories are called folders because Microsoft is so dang cool). They're pointers, but you just can't modify the address value, and they're automatically garbage-collected (this has pros and cons of course).

[Lord Aaron]

Well IMHO HBL is a **** coding mess, it would surely benefit from a re-write, but meh, it does the dang job. This is something I guess happens to all programmers when you look at your old work, you're like "WTF this is horrible, how the heck did I write this ****". But I would never have thought it would be still be used like 5 years when I started writing it lol Community FTW!

I did make some changes to VHBL regarding old code that is no longer needed for the Vita, basically making VHBL a Vita-Only app. So far it loads a bit faster and takes up a bit less space, a I generally erstructure the whole folder layout (all the source code in the same folder was a BAD idea). But as far as I'm concern, there's no reason to recode it from scratch noting that:
- it works
- it probably works better than a recode would do knowing that some great devs such as davee and neur0n helped on it, something we wouldn't get nowadays as they aren't that active.
- there's CFWs that always overshadow VHBL, so why waste our time?

Although the time I took reading VHBL made me appreciate it way more from a developer point of view (all the hard work, all the time spent, all the devs that made it possible, everything).

[m0skit0]

all the source code in the same folder was a BAD idea

Definitely. I wanted to fix this but got no help from fellow devs at the time. At the beginning I only had a couple of files, never thought it would grow this big tbh. Novice errors.

- it works

Yeah of course it works, otherwise it would be writing not re-writing

- it probably works better than a recode would do knowing that some great devs such as davee and neur0n helped on it, something we wouldn't get nowadays as they aren't that active.

Hmmm I don't agree. The code is already there, it's a matter of structuring it better. Maybe I wasn't clear enough: I don't mean re-write from scratch, but take current code and structure it in a more... decent way. There are functions too big, files with too much stuff and other files with only a couple of lines, different function naming styles, etc... This is an open source project and code must be readable for people who want to collaborate or extract some pieces to use in other projects. Oh and all HBL devs are great devs and very nice people (except me )

- there's CFWs that always overshadow VHBL, so why waste our time?

HBL was not for running CFWs at all, it was aimed at systems that could not yet run CFW because of no kernel exploits, so users could use emulators and homebrews that needed no kernel mode.

Ok I think now we're getting too much off-topic here...

[Lord Aaron]

Hmmm I don't agree. The code is already there, it's a matter of structuring it better. Maybe I wasn't clear enough: I don't mean re-write from scratch, but take current code and structure it in a more... decent way. There are functions too big, files with too much stuff and other files with only a couple of lines, different function naming styles, etc... This is an open source project and code must be readable for people who want to collaborate or extract some pieces to use in other projects. Oh and all HBL devs are great devs and very nice people (except me )

I like these ideas