Advertising (This ad goes away for registered users. You can Login or Register)

[Tutorial] Advanced C (II)

Discuss about your favorite (gaming...or not) devices here. The most popular ones will end up getting their own categories
Programming discussions for your favorite Device
Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
Post Reply
User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

[Tutorial] Advanced C (II)

Post by m0skit0 » Sat Jan 14, 2012 1:24 pm

<< 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
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Lord Aaron
Posts: 22
Joined: Tue Oct 01, 2013 8:56 pm

Re: [Tutorial] Advanced C (II)

Post by Lord Aaron » Wed Oct 02, 2013 7:46 pm

the magic of pointers, not much else here
Advertising

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: [Tutorial] Advanced C (II)

Post by m0skit0 » Fri Oct 04, 2013 6:50 pm

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! :D
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Lord Aaron
Posts: 22
Joined: Tue Oct 01, 2013 8:56 pm

Re: [Tutorial] Advanced C (II)

Post by Lord Aaron » Fri Oct 04, 2013 7:07 pm

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).

User avatar
hgoel0974
Retired Mod
Posts: 2155
Joined: Mon Jul 23, 2012 11:42 pm
Location: New York

Re: [Tutorial] Advanced C (II)

Post by hgoel0974 » Fri Oct 04, 2013 7:12 pm

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! :D
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.
"If the truth is a cruel mistress, then a lie must be a nice girl"

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: [Tutorial] Advanced C (II)

Post by m0skit0 » Fri Oct 04, 2013 7:28 pm

Lord Aaron wrote:but you gotta thank C for it
Of course, who said otherwise :mrgreen: 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...
Lord Aaron wrote: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.
Lord Aaron wrote: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! :ugeek:
hgoel0974 wrote: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).
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Lord Aaron
Posts: 22
Joined: Tue Oct 01, 2013 8:56 pm

Re: [Tutorial] Advanced C (II)

Post by Lord Aaron » Fri Oct 04, 2013 7:51 pm

m0skit0 wrote: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).

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: [Tutorial] Advanced C (II)

Post by m0skit0 » Fri Oct 04, 2013 10:35 pm

Lord Aaron wrote: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.
Lord Aaron wrote:- it works
Yeah of course it works, otherwise it would be writing not re-writing :mrgreen:
Lord Aaron wrote:- 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 :lol: )
Lord Aaron wrote:- 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... :?
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Lord Aaron
Posts: 22
Joined: Tue Oct 01, 2013 8:56 pm

Re: [Tutorial] Advanced C (II)

Post by Lord Aaron » Sat Oct 05, 2013 2:10 pm

m0skit0 wrote: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

Post Reply

Return to “Programming and Security”