About releasing MoHH eloader source code
About releasing MoHH eloader source code
Ok I want to release an alpha version of the Medal of Honor Heroes eloader I've been working on with ab5000 and n00b81, but since I want it to be open source and I've been asked by some devs to keep some parts closed, like syscall estimation. I just want to make clear that we have discovered how to estimate syscalls with no external help (wasnt that hard though), so we have all the right to open the source. This is just to have more experienced developers' advice and consider what to do: release ALL the source or keep some parts closed.
Thanks for reading and giving your opinion :)
Thanks for reading and giving your opinion :)
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
5.55
Freeplay didn't contact me. I heard he just sought source from another eloader, that's all.
Anyway our eloader still needs a lot of optimizations, but at least we did it ourselves ;) And dude, you really learn a lot (and bang your head against a wall a lot xDDD)
Freeplay didn't contact me. I heard he just sought source from another eloader, that's all.
Anyway our eloader still needs a lot of optimizations, but at least we did it ourselves ;) And dude, you really learn a lot (and bang your head against a wall a lot xDDD)
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
Does it matter that sony also knows what it's actually doing when the source is released?
Code: Select all
int main(){
SetupCallbacks();
makeNiceGame();
sceKernelExitGame();
}
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am
I think Sony can just reverse it to know how it works, even if they dont have the source. So I think the pros have more stakes than the cons. And sincerely, I dont think our code has something Sony doesnt already know about. There are no exploit or whatsoever to be kept in secret, maybe just syscall number estimation, which is sincerely something very very simple and basic (I dont know if there are more advanced estimations).
And I dont think Sony can fight better CFW with this, because an eloader it's not a CFW. I just remind that we dont have kernel access whatsoever, so CFW are basically different as they patch kernel modules, something I cant do with user mode access only.
Please correct me if I made wrong assumptions.
And I dont think Sony can fight better CFW with this, because an eloader it's not a CFW. I just remind that we dont have kernel access whatsoever, so CFW are basically different as they patch kernel modules, something I cant do with user mode access only.
Please correct me if I made wrong assumptions.
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
-
- Posts: 107
- Joined: Sat Jan 13, 2007 11:50 am
+1 for open source eLoader.
I'm not one of the "experienced developers" in terms of firmwares and code reverse, but I think sharing this eloader's source is a good idea.
As far as "fighting custom firmware" goes, I believe Sony already have more sources than they need. After all, they do have the source code for their firmware... so as you said, I think the pros outweight the cons.
I'm not one of the "experienced developers" in terms of firmwares and code reverse, but I think sharing this eloader's source is a good idea.
As far as "fighting custom firmware" goes, I believe Sony already have more sources than they need. After all, they do have the source code for their firmware... so as you said, I think the pros outweight the cons.
The eLoader isn't complex.
It just load the ELF in memory (along with all the sections), resolve imports and jump to start address of ELF.
The really PSP-dependent part is resolving the imports.
Resolving user-to-user imports is a bit complex but it isn't the really difficult part because we can do it from user mode with no problems.
The real problem is resolving user-to-kernel imports.
Syscall estimation allow us to resolve syscalls without having kernel mode (if we can go into kernel mode then we can simple query the syscall table).
In older FWs (like 2.00) syscalls were fixed, so you can just make a file with nid-syscall pairs and the work is done.
In newer FWs (from 2.50) syscalls are randomized.
They aren't REALLY randomized so we managed to estimate them (i can't say how we do it). Estimation isn't perfect but we have got a good grade of precision, and I got some ideas to optimize it.
The problem is: If we release syscall estimation code with the eLoader, Sony will probably find another method to randomize syscalls. And if this happens, the work we have done will be nearly useless.
I'm sure they aren't going to TOTALLY randomize syscalls (it's a BIG waste of memory), but a great part of the work should be remade from scratch.
So, I think we should release the source BUT keep the syscall estimation code closed.
P.S. If the source will be released, make LITTLE changes each time. Otherwise you will probably become crazy watching excpetions xD
It just load the ELF in memory (along with all the sections), resolve imports and jump to start address of ELF.
The really PSP-dependent part is resolving the imports.
Resolving user-to-user imports is a bit complex but it isn't the really difficult part because we can do it from user mode with no problems.
The real problem is resolving user-to-kernel imports.
Syscall estimation allow us to resolve syscalls without having kernel mode (if we can go into kernel mode then we can simple query the syscall table).
In older FWs (like 2.00) syscalls were fixed, so you can just make a file with nid-syscall pairs and the work is done.
In newer FWs (from 2.50) syscalls are randomized.
They aren't REALLY randomized so we managed to estimate them (i can't say how we do it). Estimation isn't perfect but we have got a good grade of precision, and I got some ideas to optimize it.
The problem is: If we release syscall estimation code with the eLoader, Sony will probably find another method to randomize syscalls. And if this happens, the work we have done will be nearly useless.
I'm sure they aren't going to TOTALLY randomize syscalls (it's a BIG waste of memory), but a great part of the work should be remade from scratch.
So, I think we should release the source BUT keep the syscall estimation code closed.
P.S. If the source will be released, make LITTLE changes each time. Otherwise you will probably become crazy watching excpetions xD
Code: Select all
%:include<stdio.h>
int _(int __,int ___,int ____,int _____)
<%for(;____<___;_____=_____*__,____++);
return _____;%>main()<%printf
("%d\n",_(2,5,0,1));%>
You forgot that when working with PRXs you must also relocate all the stuff.
Do you really think Sony doesnt know how we could estimate syscalls? They know how they "randomize" them, so they surely know how we can estimate them, don't you think? Team Noobz already did it in their eloader.
And one of the primary reasons I want to release this open source is that other devs can contribute freely, but they cannot do that if we keep syscall closed, except providing syscall.c as a .o already compiled library, which in my opinion is as much as giving the source because it can be easily disassembled.
Do you really think Sony doesnt know how we could estimate syscalls? They know how they "randomize" them, so they surely know how we can estimate them, don't you think? Team Noobz already did it in their eloader.
And one of the primary reasons I want to release this open source is that other devs can contribute freely, but they cannot do that if we keep syscall closed, except providing syscall.c as a .o already compiled library, which in my opinion is as much as giving the source because it can be easily disassembled.
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
-
- Posts: 11
- Joined: Wed Apr 23, 2008 11:44 am
m0skit0 wrote:5.55
Freeplay didn't contact me. I heard he just sought source from another eloader, that's all.
Anyway our eloader still needs a lot of optimizations, but at least we did it ourselves ;) And dude, you really learn a lot (and bang your head against a wall a lot xDDD)
Good job mate. I completely agree, you do learn a lot when you start making these things yourself :P
Giving the source to devs is the same to open the source. Who to trust? Would those devs who get it keep syscall estimation secret? I sincerely prefer open the source. And honeslty I don't want to keep track of people and judging who deserves the source and who not.PsPfReAK wrote:What if you just send the source to developers rather then having it open to download?
Development communities work way better with open source. You have a lot of examples in real world (Linux, Firefox...). Yes I know PSP cannot be compared with open standards but I think putting this elaoder open source would benefit the whole scene. New developers can find it very useful to know how execution and linking is done in PSP with a full C example. I would have been happy to have found an example such as this one. And even if Sony changes the syscall "randomization", the scene would find a way of reversing that, as it has already done with this supposed "randomization".
They didnt do so with Noobz eloader. And I doubt they will with this prototype.Visigotico wrote:Releasing or not the source, Sony is sure to find another way to randomize the system calls, causing the eLoader to stop working.
Thanks Davee, but there's still a lot of work to be done to make this really functional.Davee wrote:I completely agree, you do learn a lot when you start making these things yourself :P
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
You're missing a point here - telling SCE engineers to reverse something costs a lot of money. Money that they most likely will not spare.
By your logic, Sony could've started randomizing NIDs the moment stuff patching the kernel started appearing (ie. 1.50 times). Remember the wildc*rd source leak? That's when Sony started randomizing NIDs, when they got their hands on the -source-.
There's (usually) a reason why something stays closed-source. Be it financial or whatever, but often it's good.
By your logic, Sony could've started randomizing NIDs the moment stuff patching the kernel started appearing (ie. 1.50 times). Remember the wildc*rd source leak? That's when Sony started randomizing NIDs, when they got their hands on the -source-.
There's (usually) a reason why something stays closed-source. Be it financial or whatever, but often it's good.
Thanks for pointing that, MaTiAz.
Yeah, Sony should spend money to reverse scene stuff, which they'll unlikely do. But it should also spend more money to change the current syscall randomization. The point is they already know the scene can estimate the FW syscalls, and without doubt they also know where the flaw lies (or else their engineers are really stupid), but they haven't done a thing to prevent this from Noobz's eLoader times (2.7x iirc).
Will the source of an unfinished eloader for an already patched game exploit make them spend more money just to patch a flawed syscall randomization they're using for 4 FW major versions now?
Yeah, Sony should spend money to reverse scene stuff, which they'll unlikely do. But it should also spend more money to change the current syscall randomization. The point is they already know the scene can estimate the FW syscalls, and without doubt they also know where the flaw lies (or else their engineers are really stupid), but they haven't done a thing to prevent this from Noobz's eLoader times (2.7x iirc).
Will the source of an unfinished eloader for an already patched game exploit make them spend more money just to patch a flawed syscall randomization they're using for 4 FW major versions now?
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
The very fact you are telling us the hint is enough to alert Sony and make their mind up to change the way to "randomize" their kernel NID again. So having the source or not doesn't change anything for Sony as changing them is safer than reading source or reverse-engineering it.ab5000 wrote:The problem is: If we release syscall estimation code with the eLoader, Sony will probably find another method to randomize syscalls. And if this happens, the work we have done will be nearly useless.
I'm sure they aren't going to TOTALLY randomize syscalls (it's a BIG waste of memory), but a great part of the work should be remade from scratch.
So, I think we should release the source BUT keep the syscall estimation code closed.
-
- Posts: 107
- Joined: Sat Jan 13, 2007 11:50 am
-
- Posts: 11
- Joined: Wed Apr 23, 2008 11:44 am
Sorry for reviving this again, but II finally decided to release it, but keep syscall estimation closed until I can discuss the matter personally with ab5000, as he coded that part, although I had the idea on how to estimate them.
I still think opening the source has more benefits than keeping it closed. Closeness only endangers the freedom of the scene by concentrating code towards one direction and enhances secrecy over cooperation. And I dont think that's good for any community, and definitely only benefits Sony, first advocate for secrecy.
Hope you understand my position
I still think opening the source has more benefits than keeping it closed. Closeness only endangers the freedom of the scene by concentrating code towards one direction and enhances secrecy over cooperation. And I dont think that's good for any community, and definitely only benefits Sony, first advocate for secrecy.
Hope you understand my position
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
-
- Posts: 3
- Joined: Fri Nov 27, 2009 5:24 am
- Location: lauisiana
-
- Posts: 3
- Joined: Fri Nov 27, 2009 5:24 am
- Location: lauisiana
-
- Posts: 3
- Joined: Fri Nov 27, 2009 5:24 am
- Location: lauisiana
-
- Posts: 107
- Joined: Sat Jan 13, 2007 11:50 am
I guess willow was more likely referring to "mohh eloader"... so no need to take it personal for you :)m0skit0 wrote:I'm the answer to nothing. I only do as I please. Don't like it? Make the eloader yourself, whining boy.
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl