If you try to use up the memory via the browser it comes up with a 'low on memory' message w/ firmware 1.60: you can use the browser to view folding stats ect while folding.. but you don't have full control of the browser during folding (ex, no inputing of urls, ect).. you can just follow links. but if you play around enough on the folding stat and faq pages, you'll find a link to google.. where you can do searches, then click links to web pages you want. if you load a page that has too much crap on it (ex, images, ect..) it will give you a 'low on memory message, and it won't load the webpage. i guess the folding client is only allocated a certain amount of memory, or something like that, and the browser in that setting is limited to the memory allocated for the folding client.
of course i am only guessing about the memory allocation, ect.. as i don't know what really is the reason for the 'low memory' message.
This swapping crap isnt the key... We need to find a way to piggy back legit code. Paradox makes mention of Dark Alex several times. esentially what did he do to the psp? Well he is piggy backing sony's own made code and adding his own. Using their own modules against them right? He has to to pass Sony's checks and such. We dont want to fight the system, we want to work with it. We dont know anything of Ps3's Hyper Visor. Thats not importaint, whats importaint is manipulating the code to crash the spe and that will crash HyperVisor. execute ps2 code to gain simple access to the kernel.
Now how does the ps3 go into ps2 mode? What access does ps2 have to the kernel? Hypervisor is there.... Regardless of mode. Press the ps button and ps3 os is there. THATS THE KEY. Sony is stupid. So what did they forget to protect in ps2 mode. Its not going to be an exploit we currently use, ohh no they arent that dumb. Focus on what your going to execute, before the method of execution. We have tons of media to execute from, but no code to run... If we know so much about ps2 like we say we do, then lets crash this "ps2" Its still a ps2 right?
I have still been just comparing saved files too see if there is any difference between a save on PS2 and the same save on the PS3. I'm curious to see if its possible to inject some new code inside a game save (similiar to independent exploit).
Also I have been running a program called Lepton's Crack for Windows on a pkg file just to see if anything turns up. As unlikely as it is, the readme says it has the ability to decrypt many different algorithm's including SHA1. Its been running for about 20 hours now and still nothing but I will give it a few days just for a laugh.
I hate to say it, but please, post things more sensible! The Independence Exploit did not work on the slims (of which the PS2 in the PS3 is), as it was patched, not to mention it used a PSX exploit to launch PS2 code! Launching PS2 code isnt the problem, its launching PS3 code!
Edit: Otheros.bld is nothing more than a compressed vmlinux, theres nothing myserious about it. Get the PS3/CELL patches against the linux mainline kernel = all the goodies w/ hypervisor calls etc if your interested!
has anyone followed up on the old hint from pdx - the hint : "He discoverd that the first sectors from a PS3 image (sector 0 till 20) are special, are they the decryption keys for the excutables? (EBOOT.BIN)."
this may well be the clue to the second part of the loader? prehaps the iso needs to be patched with a modified eboot.bin ?
I have been digging through the patches for linux kernel and on the the PS3 Cell source CD. I notice they refer to patching things related to the hypervisor. If the hypervisor is accessible from the kboot prompt, we can run code their to try things? If the system can flash the kboot area, can that program be modified to read/write the XMB area?
Some info that looked interesting:
"[POWERPC] Avoid hypervisor statistics calculation in real mode kexec invokes plpar_hcall hypervisor call in real mode. plpar_hcall refers to per cpu variables for accounting hypervisor statistics.These variables may not be in the RMO region, so accesses to them in real mode may result in a data storage exception.
This fixes this problem by using a new plpar_hcall_raw function which does not update the hypervisor call statistics. Thanks to Anton for suggesting this idea."
"Subject: spufs: wrap mfc sdr access
From: Masato Noguchi <[email protected]>
SPRN_SDR1 and the SPE's MFC SDR are hypervisor resources and are not accessible from a logical partition. This change adds an access wrapper."
Just posting things that might trigger thoughts with somebody else.
Does anybody have GIT installed to look at kernel sources? I am curious about the following section: http://www.kernel.org/pub/scm/linux/...it/description
Unfortunately, I am having a difficult time with the programming aspects of trying exploits.... If it is not VB or VC#, I have trouble understanding it all. Do we have any programmers on here that would be willing to help out on any ideas that we can come up with to try?