Some more updates: [Register or Login to view links]Sponsored Links
Hm, guys, i took a closer look at PS2 Soft EMU yesterday and it uses lots of LPM (Logical Performance Monitor) HV calls What for i wonder ? For debugging ?
PS2 soft emu kernel doesn’t use only HV calls, but it uses also syscalls in kernel itself
And PS2 emu uses A/V Manager and System Manager VUART
WOOOOOOOW It has also access to Dispatcher Manager VUART 10 !!!
PS2 emu uses e.g. 0◊5005 (Authenticate PS2 Disc) service of Storage Manager
The now famous, graf_chokolo, gave a crash course on his decryption payload, today on IRC. Our good friend Heden happened to be in attendance, and provided us with a log from the chat. This should come in handy, for folks needing clarification in getting his payload to work.Sponsored Links
clean code:[23:06] <@graf_chokolo> so guys should i start ?
[23:06] Hi all
[23:06] ok what is my first step here?
[23:06] psgroove modification?
[23:06] <@arunningp> graf_chokolo everyone is here now...please start
[23:06] <@theruler_> ^ this.
[23:06] <@graf_chokolo> ok
[23:07] <@arunningp> everyone else...let himtalk
[23:07] <@graf_chokolo> i use 2 stages to run my code
[23:07] <@graf_chokolo> 1st stage is kinda bootloader for 2nd stage because psgroove allows only small piece of code
[23:08] <@graf_chokolo> so first i program psgroove with my 1st stage
[23:08] <@graf_chokolo> it's always the same
[23:08] <@iLLNESS> yo
[23:09] <@graf_chokolo> it creates a memory region of 64kb for 2nd stage and receives 2nd stage binary rom PC via Ethernet, stores received binary in this memory and executes it
[23:09] <@graf_chokolo> so far clear ?
[23:09] <@iLLNESS> yes..
[23:09] <@frank> prove it ^
[23:09] <@iLLNESS> i got a quick question
[23:09] <@graf_chokolo> ok
[23:09] <@iLLNESS> your payload is slightly different from psgroove
[23:09] <@frank> is that kilobits or bytes?
[23:10] <@graf_chokolo> completely different :-)
[23:10] <@iLLNESS> i mean, the layout of it
[23:10] <@iLLNESS> [Register or Login to view links]
[23:10] <@iLLNESS> payload.h is the bootstrap header?
[23:10] <@graf_chokolo> first i compile bootloader and convert it to C hex and store it in payload.h
[23:11] <@graf_chokolo> then i include it into psgroove desc
[23:11] does your memory region
[23:11] <@iLLNESS> okay. the pastie link i just provided is the port1 config descriptor in full? aka no extra padding?
[23:11] protected against overwriting
[23:12] <@frank> original psgroove?
[23:12] <@graf_chokolo> iLLNESS: it's complete psgroove desc i use, copied from my code, so you can just use it
[23:12] <@graf_chokolo> there are more psgrooves ?
[23:13] <@iLLNESS> what commands are you using for the bin2hex?
[23:13] <@iLLNESS> oh nm
[23:13] <@iLLNESS> i see the makefile
[23:13] <@graf_chokolo> ./bin2hex bootstrap.bin > payload.h
[23:13] <@frank> PL3 is in the new one, and iirc the FACEBOOK doesn't exist in it
[23:14] <@graf_chokolo> i use an old psgroove version
[23:14] <@graf_chokolo> and compile everything with IBM's ppu cross compiler
[23:14] <@frank> i know , just wanted to make sure + let them know
[23:15] <@graf_chokolo> more questions ?
[23:15] memory region
[23:15] <@graf_chokolo> ah, ok, sorry
[23:15] no prob
[23:15] <@graf_chokolo> i allocate the memory direct by using HV call so, gameos doesn't even see it :-)
[23:16] <@graf_chokolo> it's hidden from gameos
[23:16] This is what i thought
[23:16] no worry about overwritten
[23:16] <@graf_chokolo> yeah
[23:17] <@graf_chokolo> something unclear maybe ? don't hesitate to ask
[23:17] it's ok
[23:18] <@graf_chokolo> when 1st stage runs, it expects you to send the 2nd stage via Ethernet
[23:18] <@graf_chokolo> i use sendfile for this
[23:19] <@graf_chokolo> you will find it payload/tools
[23:19] <@graf_chokolo> in*
[23:19] <@iLLNESS> what are the symptoms of a successful boot with the bootstrap?
[23:20] <@iLLNESS> ps3 is black screened with light on
[23:20] <@iLLNESS> power light that is
[23:20] <@graf_chokolo> ps3 hangs :-) gameos shouldn't boot, but i could put a beep into bootstrap :-) then you will here it when it's ready
[23:21] <@iLLNESS> yeah that would be good
[23:22] <@graf_chokolo> ps3 should send ACKs for every received packet, sendfile will give you feedback about this
[23:22] <@iLLNESS> i get 'nothing to be done for 'all' when compiling your sendfile
[23:22] <@graf_chokolo> maybe it's already compiled ?
[23:23] <@iLLNESS> a new error
[23:23] <@iLLNESS> sendfile.c:20: fatal error: libnet.h: No such file or directory
[23:23] <@iLLNESS> what are the requisites for compiling this?
[23:23] <@iLLNESS> pre-requisites that is
[23:23] <@graf_chokolo> you need libnet library, libpcap also
[23:24] <@graf_chokolo> so, after the last packet of 2nd stage is received, 1st stage is done and jumps to 2nd stage and executes it
[23:25] <@iLLNESS> which distro are you using this on?
[23:25] <@graf_chokolo> arch linux x86
[23:25] <@frank> ill, probably port to win32
[23:25] <@iLLNESS> your porting to win32?
[23:25] <@graf_chokolo> i quit :-)
[23:25] <@theruler_> lol
[23:26] <@frank> lol, why so soon?
[23:26] win32 !
[23:26] <@frank> guys use ubuntu
[23:26] <@arunningp> ill keep a tally for how many times graf quits :P
[23:27] <@frank> i just prefer VS
[23:27] <@graf_chokolo> it doesn't matter which linux are you using :-) arch linux is just my favorite and dwm manager :-)
[23:27] Then 2nd stage
[23:28] <@iLLNESS> ack.
[23:28] <@iLLNESS> core/config.c:111: error: ignoring return value of ‘fgets’, declared with attribute warn_unused_result
[23:28] <@iLLNESS> make: *** [core/config.o] Error 1
[23:29] "bootloader" == "bootstrap" == "stage 1" ? just want to keep the terms clear
[23:29] you need LATEST libpcap
[23:29] <@iLLNESS> im trying to install libnet
[23:29] <@graf_chokolo> thomas, correct
[23:29] this is being logged to make into a nice tutorial
[23:30] <@graf_chokolo> no problem with that, everything is public anyways, just in code
[23:31] <@graf_chokolo> so, in main.c of 2nd stage you will find many function calls, most of them are disabled, mm_init, gelic_init and param_init should never be disabled
[23:31] mm_init returns 0
[23:31] <@graf_chokolo> to make self decrypter payload e.g. activate decrypt_self call
[23:31] <@graf_chokolo> 0 means success
[23:32] yeah this is the only line
[23:32] if i remember
[23:32] <@graf_chokolo> to make lv2 decrypter activate decrypt_lv2_direct call and so on
[23:32] <@graf_chokolo> after that compile 2nd stage
[23:33] <@graf_chokolo> you will get payload.bin which you have to send to 1st stage with sendfile
[23:33] <@graf_chokolo> questions ?
[23:33] * thomas is using fedora 14 ... fwiw
[23:33] <@graf_chokolo> i quit :-)
[23:33] <@arunningp> thats 3 so far...
[23:33] I did tell you that I had a problem of linker
[23:34] for this one
[23:34] <@frank> graf_chokolo, never give up
[23:34] <@arunningp> never surrender
[23:34] toilets ?
[23:34] <@graf_chokolo> Heden_DLT, with IBM's ppu compiler ?
[23:35] coffee ?
[23:35] no choko
[23:35] I don't use this one
[23:35] I should ?
[23:35] <@graf_chokolo> hm, i only tested with IBM's ppu compiler, not sure about others
[23:35] Once lv1 functions compiled
[23:35] <@graf_chokolo> with IBM's compiler i have no problems at all
[23:36] the linker cannot find them
[23:36] but continue
[23:36] I'll will look deeper
[23:37] <@graf_chokolo> ok, we can discuss your problems with compiler another day
[23:37] <@graf_chokolo> ok, now you send payload.bin to bootloader, it receives it and executes
[23:37] <@iLLNESS> would libpcap-dev be okay to use?
[23:37] <@graf_chokolo> yeah
[23:38] <@graf_chokolo> i assume now that we want to decrypt selfs
[23:38] <@graf_chokolo> should i go deeper into details or just user manual ?
[23:39] I just see
[23:39] <@frank> when will women stop *****ing
[23:39] <@theruler_> never.
[23:39] that you isolated a SPU
[23:40] <@frank> when all men are dead
[23:40] <@theruler_> :P
[23:40] <@iLLNESS> damnit
[23:40] <@iLLNESS> still get libnet errors
[23:41] put your self in memory
[23:41] and ask the spu to decrypt it using a mailbox
[23:41] <@theruler_> @Rich: You following along or how are you making out?
[23:41] <@graf_chokolo> you are looking at decrypt_self.c or decrypt_self_direct.c ?
[23:42] me ?
[23:42] <@iLLNESS> inflate.c:20: fatal error: zlib.h: No such file or directory
[23:42] <@graf_chokolo> yeah
[23:42] <@graf_chokolo> install zlib
[23:42] choko : decrypt_self.x
[23:42] choko : decrypt_self.c
[23:42] <@graf_chokolo> you need inflate for decrypting update packages
[23:43] <@graf_chokolo> i do not load isolated module (appldr) manually, HV call 99 does it, in decrypt_self_direct.c i do it manually
[23:44] inflate or deflate ?
[23:44] sorry graf, one question ... what is the difference between the config_descriptor you provided in the pastie, and the stage1 bootstrap? I ask because the bootstrap I compile is MUCH larger
[23:44] <@graf_chokolo> zlib calls it inflate
[23:44] <@frank> like a balloon
[23:45] <@graf_chokolo> bootstrap.bin ?
[23:45] right, now bootstrap.hex via bin2hex
[23:46] <@graf_chokolo> compile bootstrap.bin, convert it to payload.h with ./bin2hex bootstrap.bin > payload.h and place payload.h into psgroove dir
[23:46] are they the same? I compiled from latest git
[23:47] <@graf_chokolo> then compile psgroove and flash it
[23:47] <@graf_chokolo> but use my config desc and not the one from psgroove
[23:47] <@iLLNESS> i have the bootstrap compiled if you guys want it
[23:47] <@iLLNESS> just give me board info
[23:48] <@iLLNESS> i cant compile the payload tools though
[23:48] when you say you use an old version of psgroove, do you suspect latest git (with PL3) to be incompatible?
[23:49] <@frank> grab the one that added peek/poke
[23:49] <@iLLNESS> i got it
[23:49] <@theruler_> sweet
[23:49] <@graf_chokolo> hm, really don't know, because i compiled bootstrap once, flashed psgroove and have not changed it since ages
[23:49] <@iLLNESS> thomas, i used evilsperms psgroove fork for this
[23:49] <@iLLNESS> just remove the #ifdef before port1 config descriptor
[23:49] a stupid question choco
[23:49] <@iLLNESS> as well as the #endif
[23:49] <@frank> ya, peek/poke was my last update, so i haven't changed it, heh
[23:50] all packets received and sent
[23:50] <@graf_chokolo> waiting for question
[23:51] are done with a "simple" ETH link between PC and PS3 ?
[23:51] <@graf_chokolo> i have a router and ps3 and pc are connected to it
[23:52] <@graf_chokolo> ps3 sends packets with broadcast dest mac addr
[23:52] Gelic gives the opportunity then to a direct link ?
[23:53] <@graf_chokolo> gelic is just a low level device driver which sends raw ethernet frames
[23:53] <@graf_chokolo> i do not use IPv4 :-)
[23:53] <@frank> no layer 3? :O
[23:53] <@graf_chokolo> so to use sendfile you need root rights
[23:54] <@graf_chokolo> no, i wanted first to use UDP but i thouth then what for ?
[23:54] <@frank> i know, just pulling ur leg
[23:54] <@graf_chokolo> :-)
[23:55] <@graf_chokolo> no more questions ?
[23:55] I have done this to the descriptor.h file... [Register or Login to view links]
[23:56] <@graf_chokolo> looks fine i would say
[23:56] <@graf_chokolo> so about self decrypter
[23:56] <@graf_chokolo> it expects you to send a SELF which it will decrypt
[23:57] <@graf_chokolo> so grab some SELF and again use sendfile to send it to ps3
[23:57] <@graf_chokolo> you should see ACKS comming from ps3
[23:58] <@graf_chokolo> sendfile will give you feedback about that
[23:58] <@graf_chokolo> it is also ok if some packets get lost, sendfile will retransmit it
[23:59] <@graf_chokolo> but before sending a SELF start tcpdump to capture the decrypted segments sent by ps3
[23:59] <@graf_chokolo> or else you could miss them if you are not fast enough :-)
[00:00] <@graf_chokolo> after self decrypter is done it should make 2 beeps :-)
[00:00] double beep
[00:00] <@graf_chokolo> yeah, and now you can terminate tcpdump
[00:01] <@graf_chokolo> it should contains decrypted segments now
[00:01] <@graf_chokolo> which are impatient to be reversed by you :-)
[00:01] <@arunningp> lulz
[00:01] yet the problem
[00:02] to separate payload
[00:02] from "header"
[00:02] <@graf_chokolo> no problem :-)
[00:02] <@graf_chokolo> i send decrypted segmnets with Ethernet protocol field starting with 0xBEEF :-)
[00:03] <@frank> yum
[00:03] right ?
[00:03] <@graf_chokolo> so data from 1st decrypted segment has protocol 0xBEEF, data from 2nd decrypted segment has protocol 0xBEEF+1 and so on
[00:03] <@graf_chokolo> yeah, right
[00:03] nice !
[00:04] 0xCAFE is better
[00:04] <@graf_chokolo> now use pcap2bin and dump_segs_from_pcap.sh to extract those segments
[00:04] <@graf_chokolo> segments are pure ppc asm :-)
[00:05] <@graf_chokolo> no, in case of executable files the 1st segment contains also ELF header
[00:05] a true ELF ?
[00:05] <@graf_chokolo> and strings of course
[00:05] <@graf_chokolo> no, not true ELF ready to run
[00:06] I saw a tutorial
[00:06] using zlib to reconstruct
[00:06] <@graf_chokolo> just segments of ELF, but you can make an ELF, for reversing you don't need true ELFs
[00:06] <@graf_chokolo> zlib ?
[00:07] <@graf_chokolo> segments are not compressed, appldr already decompressed them
[00:08] look : [Register or Login to view links]
[00:08] <@graf_chokolo> yeah, but why compressing them ?
[00:09] well good question
[00:09] <@graf_chokolo> that's not all guys
[00:09] <@graf_chokolo> you have got now segments, but to reverse it you also need load addresses of these segments
[00:10] <@theruler_> @thomas/@iLLNESS: you guys still following along?
[00:10] <@graf_chokolo> ask questions if you have any, i will help
[00:11] <@graf_chokolo> no questions ?
[00:11] i will have
[00:11] concerning LV2..
[00:11] But I let the others
[00:11] <@graf_chokolo> yeah
[00:11] finish with this step
[00:12] <@graf_chokolo> guys, ask me anything, don't hesitate, i won't laugh you out
[00:12] <@arunningp> although he might quit :P
[00:13] choko ?
[00:13] <@graf_chokolo> so no questions then ? :-)
[00:13] <@theruler_> not sure if thomas/ill are AFK or what
[00:13] <@theruler_> but if heden is good you can keep going
[00:13] ok, got it compiled and my minimus flashed ... first boot looks successful! \o/ ps3 is at black screen and minimus blue light is off
[00:13] <@theruler_> great job thomas
[00:14] <@graf_chokolo> try to send something with sendfile, you should see acks
[00:14] * thomas is up-reading ...
[00:14] the way you described is simply amazing
[00:15] Now..let's talk if you want
[00:15] ok, as far as tcpdump goes, *what* should I be looking for, udp? port?
[00:15] <@graf_chokolo> you know tcpdump a bit ?
[00:16] <@graf_chokolo> you could e.g. filter only traffic comming from ps3's mac address
[00:16] ok, I should be using a cross-over cable?
[00:16] or was I supposed to set an IP address somewhere?
[00:16] ie destination
[00:16] <@graf_chokolo> hm, i used router, didn't try cross over
[00:17] <@graf_chokolo> i don't use IP, just Ethernet
[00:17] my sniffer(tcpdump) and the ps3 are on the same switch, but its a switch not a hub
[00:17] thomas : try a direct link ?
[00:17] <@graf_chokolo> ps3 use brodcast dst addr so it should be no problem
[00:18] that I think answers my question
[00:18] <@graf_chokolo> i mean filter for eth src addr of ps3
[00:18] <@graf_chokolo> not dst
[00:19] <@graf_chokolo> more questions ?
[00:19] does all worl on old fat PS3 ?
[00:19] thomas : slim or fat ?
[00:19] is it by chance sending anything periodicall?
[00:19] fat 3.15
[00:20] <@graf_chokolo> i have not tried it yet, but intend to do it, someone reported that it has problems with FATs
[00:20] <@graf_chokolo> i use slim
[00:20] thomas seems to success on a fat
[00:20] <@graf_chokolo> but i will test it in the next days with a fat
[00:21] I have a minor chicken/egg problem atm ... it is booted with payload, but arp -a gives me an incomplete address ... let me read up this tcpdump that has been running for 2 days watching the ps3 to see if mac is in there
[00:21] <@graf_chokolo> you need the filter for tcpdump, just capture everything, no problem with that
[00:21] <@graf_chokolo> don't need*
[00:22] <@graf_chokolo> you can use it but it's not required
[00:22] may i continue thomas or you need details from choco ?
[00:22] go on
[00:23] sure ?
[00:23] choko ?
[00:23] <@graf_chokolo> yeah
[00:39] a big thank to theruler
[00:39] and choko
[00:39] <@graf_chokolo> yeah
[00:40] <@theruler_> @graf: thanks for all your help
[00:40] bye bye
On decrypter payload [Register or Login to view links]
graf, is your payload to be used with psgroove?
yeah, psgroove, it uses 2 stages
boostrap is programmed into psgroove
payload is sent to ps3 via ethernet
payload is what does the real job :-)
i did it that way because you cannot program psgroove with large piece of code
bootstrap.bin have to be converted to C hex and inserted into psgroove descriptor
i can upload my psgroove descriptor, it's no problem
ok, here is my psgroove desc
[Register or Login to view links]
just convert bootstrap.bin to payload.h with bin2hex tool i provided
the bytes after payload.h doesn't matter, they are just dummies
program your psgroove with this bootstrap
bootstrap has one purpose, it received payload.bin from me via ethernet and runs it :-)
this way i can run huge piece of code :-)
and do not need to reprogram my psgroove everytime, have just to change payload and it does something different
i'm using tcpdump to capture verything that comes back from ps3 and extract it then with pcap2bin
you can also use wireshark if you want to
payload.bin is sent to ps3 with sendfile tool i provided
and a self to decrypt e.g. is also sent with sendfile via ethernet
all data sent to ps3 is acked by ps3, to make sure that file transferred to ps3 is ok
because sometimes a ethernet frame can get lost
to be able to decrypt selfs you have first to edit main.c file and uncomment it, make sure only self decrypter will be called in main
except mm and gelic
to decrypt selfs, first run psgroove with programmed bootstrap
wait some time till it runsa
then send payload.bin
data sent to ps3 should be acked,sendfle will give you feedback
if it doesn't see any acks then there is a problem
i think here it would be best to test it with your ps3
when payload.bin is uploaded to ps3 it will be executed immediately
if the payload.bin does self decryption then it waits now for you to send it some SELF file to decrypt :-)
so send a SELF to ps3 with sendfile
but before that make sure you start tcpdump to capture the data coming back from ps3 :-)
because the data will contain the decrypted SELF segments :-)
every decrypted self segment is sent using different Ethernet protocol field values
i do it for one purpose, to make extracting decrypted segments easier
here an example
if a SELF has 2 encrypted segments, i send 1st decrypted segment with Ethernet protocol field value 0xBEEF, and the 2nd one i send
with protocol (0xBEEF+1)
so to extract the 1st segment from tcpdump pcap file i just use "pcap2bin -p 0xBEEF "
so to extract the 2nd segment from tcpdump pcap file i just use "pcap2bin -p 0xBEF0 "
and now you have 2 decrypted segments :-) which are impatient to be loaded into IDA for reversing, but that's not all :-)
forgot to say. when self decrypter is done, ps3 should make 2 beeps :-)
you need also the right load addresses for those segments in order to be able to reverse it
self decrypter sends not only decrypted segments to you, it sends more data :-)
graf_chokolo> one of the packets sent to PC by self decrypter contains load address of segment, take a look at decrypt_self.c and you will understand what i mean
this paxket is sent just before the decrypted data is sent
so now you have everything to do reversing with IDA
just load these segments into IDA at right addresses
i see... this could have been done neater but its better than nothing
Some more updates: [Register or Login to view links]
Guys, iím able now to decrypt all SELF upto 3.41 firmware using appldr directly without HVCALL 99 Just decrypted vsh.sekf from 3.15 firmware with this method. I will make everything public very soon And then you will see the low level interface to appldr. Itís partially hidden by lv1_undocumented_function_99
Guys, look at wahta i have found in sysconf_plugin.sprx
OtherOS support is still there
Here is a snippet from sysconf_plugin.sprx 3.41:
[Register or Login to view links]
So this does mean that the code for the otheros is still in the driver of the ps3. Then i'm right with that they have patched it out from kernel.
We will see, one step after the other.In a few we will dump the whole flash including all boot files and also we will decrypt them to be able to bring back otheros. (if its possible)
Big thx to grafchokolo and his payloads and also for teaching me how to use his tools.
Oh and to all others sooo nice sceners they tried to direct us in the wrong direction... i'm maybe no learned coder..but im' also no noob and i hack consoles with love from heart.And if i need a reall coder to get the thing done, ill find one and do it.
I'm sure the code is still in there, why would they bother removing all of it when they can just remove the menu options for launching the formatter, installer and setting the boot flag. When it was taken out the system was still locked up so they didn't have to worry about scraping every piece of code out.
But why all the interest in otherOS? can't people just downgrade or use asbestOS to get it back if they want it back that badly.
Still looking forward to seeing whats in those SELF's and how appldr really works
I for myself think its the kernel or the lv2.self.If im not wrong then i have read a post some where, where all boot files of a debug was be listed and there was also a lv2debug.self.And for what i know the service jig use a lv2diag.self.
Anyway i'll try to compile psgroove with grafchokolos bootstrap and first dump whole flash and then ill try to decrypt with his payload.
More updates: [Register or Login to view links]
graf_chokolo says: Holy crap, guys Did you know that LV2 kernel from service JIG is very different from retail version, it contains e.g. LPM (Logical Performance Monitor) and other stuff which LV2 3.41 doesn’t contain I want to install it on my FAT ps3 and dump HV kernel Maybe then i will found out how to use those isolated SPU modules contained in service JIG PUP
WOW LV2 kernel from service JIG contains a lot more debug strings
Here an example:
[Register or Login to view links]
Guys, you know how $ONY calls HVCALL99 ?
They call it: lv1_authenticate_program_segment
I released several days ago my SELF decrypter. With that you will be able to decrypt all SELFs upto 3.41 firmware. The payload is in file decrypt_self_direct.c. It uses metldr and appldr directly to decrypt SELFs.
Furthermore, you will need a revoke list for programs which can be extracted from PUP files. Have fun guys
Thats reall great
I knowed it. The debug strings for debug system settings, debug update settings along some more are in the kernel. Also i'm pretty sure that otheros is patched out of kernel. So dumping and decrypting some debug and retail kernels from diff versions will be main goal to enable the missing options.
More updates: [Register or Login to view links]
You can decrypt lv2_kernel.self frim Service JIG by using lv2ldr. No need to install it in order to be able to dump it
I uploaded my VUART hook. While your GameOS runs, it communicates with VUARTs 0 (A/V Manager), 2 (System Manager) and 10 (Dispatcher Manager). The VUART hook sends all data written to or read from these VUARTs via Eternet. In this data you will find e.g. communication with Update Manager, Sorage Manager (Disc Authentication etc), Virtual TRM Manager or USB Dongle Authenticator and lots of other very interesting stuff
Aha GameOS uses service 0x200D (Decrypt with Portability) of Virtual TRM Manager to decrypt something
I just tested my code on PS3 FAT with 3.15 and managed to make it work with the latest PSGroove version You donít have to change anything in my code, itís independent of firmware or PSGRoove version. I uploaded new sendfile version which doesnít use VLAN per default, use it with 3.15, if you want to use VLAN just add -v option.
Here is my descriptor for the latest PSGRoove version:
[Register or Login to view links]
12 - CONTROL_LED
- I have tested this service with PSGroove and GameOS is allowed to use it.
- GameOS syscall 386 uses this service.
[Register or Login to view code]
I have tested the following parameters with this service:
21 - RING_BUZZERfield0 field1 field2 field4 field5 Description
0x1 0x0 0xFF 0xFF 0xFF Turns off the power button LED
0x1 0x1 0xFF 0xFF 0xFF Turns on the power button LED
- I have tested this service with PSGroove and GameOS is allowed to use it
[Register or Login to view code]
- I have tested the following parameters with this service:
HV callfield1 field2 field4 Description
0x29 0x4 0x6 Makes a short single beep
0x29 0xA 0x1B6 Makes a double beep
0x29 0x7 0x36 -
0x29 0xA 0xFFF Makes a continuous beep
- The address of HV table is stored at -0x6FC8(HSPRG0).
- The address of HV table size is stored at -0x6FD0(HSPRG0).
Memory HV callId Name Description
62 lv1_undocumented_function_62 SPE (isolation, it updates a SLB entry, writes to SLB_Index, SLB_VSID, SLB_ESID and SLB_Invalidate_Entry registers)
89 lv1_undocumented_function_89 SPE (writes to MFC_TLB_Invalidate_Entry register)
99 lv1_authenticate_program_segment SPE (isolation, syscall 0x10043, syscall 0x10042, syscall 0x1004A)
102 lv1_undocumented_function_102 Returns current TB ticks
137 lv1_undocumented_function_137 SPE
138 lv1_undocumented_function_138 SPE
167 lv1_undocumented_function_167 SPE (isolation, reads from SPU_Out_Intr_Mbox and MFC_CNTL registers)
168 lv1_undocumented_function_168 SPE (isolation, writes to MFC_CNTL register)
195 lv1_undocumented_function_195 WLAN Gelic device
196 lv1_undocumented_function_196 WLAN Gelic device
200 lv1_undocumented_function_200 SPE (isolation)
201 lv1_undocumented_function_201 SPE (isolation)
209 lv1_undocumented_function_209 SPE (isolation)
250 lv1_undocumented_function_250 Storage device
251 lv1_undocumented_function_251 Storage device
252 lv1_undocumented_function_252 Storage device
253 lv1_undocumented_function_253 Storage device
- All memory HV calls branch to lv1_mm_call
- lv1_mm_call has it's own function table
- Memory HV call number = HV call number
Memory HV call table
- Each entry is a pointer to a function TOC entry.
- table size = 256
- 0x00364208 (3.15)
Memory HV calls
lv1_map_htab - 0x002D595C (3.15)
lv1_unmap_htab - 0x002D56B8 (3.15)
lv1_allocate_memory - 0x002D72F0 (3.15)
lv1_release_memory - 0x002D66A4 (3.15)
lv1_query_logical_partition_address_region_info - 0x002C9B24 (3.15)
lv1_create_repository_node - 0x002DD014 (3.15)
lv1_get_repository_node_value - 0x002DD260 (3.15)
lv1_undocumented_function_231 - 0x0030B560 (3.15)