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

FreeMem()

This is the development forum of the half-byte loader project. For general Half Byte Loader questions, visit the Half Byte Loader forum.
Forum rules
This forum is for HBL Development discussions ONLY. For User support or HBL general discussions, go to viewforum.php?f=3 . Messages that are not development related will be deleted.
some1
HBL Collaborator
Posts: 139
Joined: Sun Dec 12, 2010 4:19 am

FreeMem()

Post by some1 » Wed Dec 15, 2010 4:13 pm

Here's a quick update so GAME_FREEMEM_ADDR can be an array

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
	u32 i;
	SceUID memids[] = GAME_FREEMEM_ADDR;
	
	for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
	{
		int ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
		if (ret < 0)
		{
			LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
		}
	}
}
#endif
Not sure if this was the best way to do it, but just a quick fix, I've only tested with two addrs's in the array.

Thanks to Freddy for helping fix a problem in the above code
Advertising
way to keep a secret malloxis...erm jeerum
Hmm, a demo user mode exploit doesn't seem as important anymore, I wonder why... xP

User avatar
FrEdDy
HBL Collaborator
Posts: 243
Joined: Mon Sep 27, 2010 7:08 pm
Contact:

Re: FreeMem()

Post by FrEdDy » Wed Dec 15, 2010 4:41 pm

some1 wrote:Here's a quick update so GAME_FREEMEM_ADDR can be an array

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
	u32 i;
	SceUID memids[] = GAME_FREEMEM_ADDR;
	
	for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
	{
		int ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
		if (ret < 0)
		{
			LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
		}
	}
}
#endif
Not sure if this was the best way to do it, but just a quick fix, I've only tested with two addrs's in the array.

Thanks to Freddy for helping fix a problem in the above code
Meh,I don't see it as a fix :P it's just a fix for your exploit
Advertising
https://github.com/freddy-156
<@n00b81> FREDDY CUTTIES

JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: FreeMem()

Post by JJS » Wed Dec 15, 2010 4:44 pm

In the long run it will become necessary to have the ability for freeing more than one memory allocation. This will break all existing GAME_FREEMEM_ADDR definitions in exploit_config.h until they are updated to be arrays.

A quick correction though:

Code: Select all

#ifdef GAME_FREEMEM_ADDR
void FreeMem()
{
   u32 i;
   SceUID memids[] = GAME_FREEMEM_ADDR;
   int ret;
   
   for(i = 0; i < sizeof(memids)/sizeof(u32); i++)
   {
      ret = sceKernelFreePartitionMemory(*(SceUID*)memids[i]);
      if (ret < 0)
      {
         LOGSTR2("--> ERROR 0x%08lX FREEING PARTITON MEMORY ID 0x%08lX\n", ret, *(SceUID*)memids[i]);
      }
   }
}
#endif
Edit: Corrected stupid mistakes.

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

Re: FreeMem()

Post by m0skit0 » Wed Dec 15, 2010 4:53 pm

I see it useful, good improvement and good idea.

And sorry but

Code: Select all

SceUID memids[];
makes no sense. Looping through an array that you don't even declare its contents, address or length :?

Also having

Code: Select all

sizeof(memids)/sizeof(u32)
on the for sentence is awful. Why compute this division on every loop? Better use another variable like

Code: Select all

num_memids = sizeof(memids)/sizeof(u32)
Anyway, I think the best solution is to declare a global external array on the exploit header file and use that. Also it would be a good idea to provide a wrapper to access those variables, not accessing directly to them but through functions.
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

some1
HBL Collaborator
Posts: 139
Joined: Sun Dec 12, 2010 4:19 am

Re: FreeMem()

Post by some1 » Wed Dec 15, 2010 5:02 pm

meh, do what ever you want, it was just a quick fix for what I'm working on, and also, I got

Code: Select all

sizeof(memids)/sizeof(u32)
From DeleteAllThreads()
way to keep a secret malloxis...erm jeerum
Hmm, a demo user mode exploit doesn't seem as important anymore, I wonder why... xP

JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: FreeMem()

Post by JJS » Wed Dec 15, 2010 6:23 pm

To be fair, this is really just in line with the existing code for freeing the threads and semaphores etc.

wololo
Site Admin
Posts: 3615
Joined: Wed Oct 15, 2008 12:42 am
Location: Japan

Re: FreeMem()

Post by wololo » Thu Dec 16, 2010 12:25 am

m0skit0 wrote:

Code: Select all

sizeof(memids)/sizeof(u32)
on the for sentence is awful. Why compute this division on every loop? Better use another variable like
"sizeof" is computed at compile time So I'm pretty sure the compiler optimizes this division for you... I also happen to know what I do from time to time. ;)
Your suggestion, on the other hand, introduces a runtime variable and risks of side effects.
You can quote me on this.

also, even if you assume that the compiler is dumb and wil do the division every time, making a division every loop on an array of a dozen entries will not have any performance impact, it's nothing compared to, for example, opening the Debug log file once.

In other words, this code is exactly what we want in that kind of case, not an additional variable
If you need US PSN Codes, this technique is what I recommend.

Looking for guest bloggers and news hunters here at wololo.net, PM me!

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

Re: FreeMem()

Post by m0skit0 » Thu Dec 16, 2010 7:46 am

It's very ugly and anyway as you say the compiler will optimize it for you (whether you use a local variable or not). Also I've not yet seen on HBL a local variable going corrupt, I don't know why you say that about it.

Anyway, I'm not going to discuss about this since it's not really relevant :mrgreen:

And to some1, don't feel upset, this is the kind of discussions we have around here. If you're not ready to discuss your code and/or ideas with other developers, I suggest you to not get involved in open source projects. We're just trying to make it shine 8-) :lol: and also try to avoid potential bugs. Also a big part of this is learning from each other.
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

wololo
Site Admin
Posts: 3615
Joined: Wed Oct 15, 2008 12:42 am
Location: Japan

Re: FreeMem()

Post by wololo » Thu Dec 16, 2010 8:02 am

You can't say in the same post that my code is "ugly" and then say you won't discuss it, you're just trying to dodge your mistake here.

I didn't say local variables would get corrupt, I said they introduced risks of side effects.

here's how:

Code: Select all

int var = sizeof(A)/sizeof(B);

[...]
var = 0;
[...]
for (i = 0; i < var; ++i) {
stuff;
}

What do you think about the following?

Code: Select all

int var1 = sizeof(A)/sizeof(B);
int var2 = var1;
int var3 = var2;
int var4 = var3;

for (i = 0; i < var4; ++i) {
stuff;
}
Because in essence, that's what you're suggesting, man.
If you need US PSN Codes, this technique is what I recommend.

Looking for guest bloggers and news hunters here at wololo.net, PM me!

JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: FreeMem()

Post by JJS » Thu Dec 16, 2010 8:16 am

Well, sizeof() will be shortened to a number by the compiler so there is indeed no problem.


The first error scenario could be avoided by using the "const" modifier on the variable.

I don't get the point of the second one tbh. If it is about whether the compiler can optimize the unnecessary variables away, I don't know.

Post Reply

Return to “Half Byte Loader Development”