Homebrew Probably Slowhax modified source code

  • Thread starter Thread starter kurocygnus
  • Start date Start date
  • Views Views 2,636
  • Replies Replies 15

kurocygnus

Well-Known Member
Newcomer
Joined
May 22, 2015
Messages
89
Reaction score
18
Trophies
1
XP
202
Country
Brazil
So, someone created a Pastebin (http://pastebin.com/nR6csEXJ) with a source code that claims to be a slowhax modified version who runs the 3ds_dsiware_installer. I compiled it and runned for about 2h and got not even close to finish. Someone who understands more about 3DS programming could say if there's a way to optimize it?
 
So, someone created a Pastebin (http://pastebin.com/nR6csEXJ) with a source code that claims to be a slowhax modified version who runs the 3ds_dsiware_installer. I compiled it and runned for about 2h and got not even close to finish. Someone who understands more about 3DS programming could say if there's a way to optimize it?

Another mysterious pastebin, i wonder who created it. Hmm..

"This is estimated to take all of two weeks to reach the cut-off!" ill wait two weeks and see if there is anything after that :p
 
Last edited by proflayton123,
Code:
printf("Slowerhax\n"); //slower version of slowhax
//POC - probably won't work and I don't have two weeks to find out
//This is estimated to take all of two weeks to reach the cut-off! Who has the time to actually test this? 
//Note: this doesn't seems to work on new3ds very well. Relaunching system apps leads to the pid not advancing or memory crashes.
Heh.
 
Last edited by Joom,
  • Like
Reactions: 44100hz
Code:
printf("Slowerhax\n"); //slower version of slowhax
//POC - probably won't work and I don't have two weeks to find out
//This is estimated to take all of two weeks to reach the cut-off! Who has the time to actually test this?
//Note: this doesn't seems to work on new3ds very well. Relaunching system apps leads to the pid not advancing or memory crashes.
Heh.

This exactly. :p
 
Lol 2 week is very very unreliable...we must wait until it take 2-10 hour at max and it tell that it doesnt work well with new 3ds!:(
Yeah. I don't understand much of 3DS programming, but I know a little C so I'm looking for some way to make it go faster.
 
Yeah. I don't understand much of 3DS programming, but I know a little C so I'm looking for some way to make it go faster.
I don't think C programming will help you at all to make this run faster.

Looking at this it tries to exploit something that's more of a theory than anything.
It basically launches a title until it hit the cutoff. After hitting the cutoff it will stop and then you exit and launch the dsiware installer.
It is suspected that the next launched title can then launch with pid 0. Which you would then use to launch the dsiwarehax installer with full svc access.

Unless you are able to make the title launch and terminate faster you can't really make it faster without any other indepth knowledge to pid assigning.

And in case of it NOT using u32 but u64 it will take 2^31 times as long.

Either way. Even if it's working, it's not a valid "solution".
 
Last edited by Zan',
might be quicker to just sit there opening and closing titles.....but doesnt applets count towards the PID count too, in which case maybe you could spam app-applet1-applet2-applet1-applet2-applet1-applet2-applet1 etc etc, afaik applets would be faster for opening and closing than a full title
 
  • Like
Reactions: peteruk
might be quicker to just sit there opening and closing titles.....but doesnt applets count towards the PID count too, in which case maybe you could spam app-applet1-applet2-applet1-applet2-applet1-applet2-applet1 etc etc, afaik applets would be faster for opening and closing than a full title
Is this for a buffer overflow? What's the maximum number you'd have to reach?
 
Is this for a buffer overflow? What's the maximum number you'd have to reach?
from what i can gather from this example attempt of exploiting it, the PID wraparound occurs at 7FFFFFFF, and afaik someone already managed to get this made and refined so it only takes 2 hours, so there has to be a way of forcing the PID faster than this method, i was pretty sure swapping applets on NTR causes the PID to still go up but doesnt have the same overhead as booting a full app so i would imagine swapping from applet to applet may fair better......then again the source here says launching system apps doesnt work and doesnt increase the PID

in which case maybe its a matter of spam closing something that the system will always restart if closed to increase faster, idk but its cool to see people having a go :)
 
  • Like
Reactions: peteruk
Is this for a buffer overflow? What's the maximum number you'd have to reach?
Kinda. You wanna reach 0xFFFFFFFF which is = 4294967295.

--------------------- MERGED ---------------------------

from what i can gather from this example attempt of exploiting it, the PID wraparound occurs at 7FFFFFFF, and afaik someone already managed to get this made and refined so it only takes 2 hours, so there has to be a way of forcing the PID faster than this method, i was pretty sure swapping applets on NTR causes the PID to still go up but doesnt have the same overhead as booting a full app so i would imagine swapping from applet to applet may fair better......then again the source here says launching system apps doesnt work and doesnt increase the PID

in which case maybe its a matter of spam closing something that the system will always restart if closed to increase faster, idk but its cool to see people having a go :)

I tried using applets. I don't know if I did right, but it seens slowly than the original.
 
  • Like
Reactions: gamesquest1

Site & Scene News

Popular threads in this forum