OpenTuna

PS2 OpenTuna - An open source version of "Fortuna", based on reverse engineering! v2.0.1

Thanks for the information - I will wait for the news. I have a chip-based 77008 slim version and a Chinese memory card without Magic Gate. At the moment I am using FCMB for Fortuna and the current version of OPL. None of the options work, FCMB 1.9.X is not installed directly. I would like to use something new and interesting. Good luck to the developers!
Don't take this the wrong way, why do you want/need to run FMCB/TUNA? if you have a modchip installed? OPL/ULE can be launched directly from the memory card with the modchip, either holding R1, R2, or setting to directly launch them from the modchip menu boot configuration, all that's needed is to create a folder called BOOT in the memory card and rename the ULE/OPL elf to BOOT.ELF and BOOT2.ELF , even if it's one of those clone of clone modchips that will break if the settings are changed, the shortcuts will work.
 
Don't take this the wrong way, why do you want/need to run FMCB/TUNA? if you have a modchip installed? OPL/ULE can be launched directly from the memory card with the modchip, either holding R1, R2, or setting to directly launch them from the modchip menu boot configuration, all that's needed is to create a folder called BOOT in the memory card and rename the ULE/OPL elf to BOOT.ELF and BOOT2.ELF , even if it's one of those clone of clone modchips that will break if the settings are changed, the shortcuts will work.
Because of initialization... Some modchips lack of it.
 
Thanks but freeze on FAT console model: SCPH-39009 :( and black screen on Slim console model: SCPH-70006 :(

I use the last version 1.0.2 :(
 
Thanks but freeze on FAT console model: SCPH-39009 :( and black screen on Slim console model: SCPH-70006 :(

I use the last version 1.0.2 :(
Thanks for reporting. To date fat models support hasn't released, only supported fat model is SCPH-5000X with ROM v1.90, so that freeze in your 39001 console is expected.

Regarding your slim console, is black screen displayed even when launching ULE by holding :but cir:? OpenTuna defaults to OPL 1.0.0 when no key is hold, so please delete any OPL configuration file in MC or USB pendrive if plugged in, and try again.
 
Last edited:
Thanks for reporting. To date fat models support hasn't released, only supported fat model is SCPH-5000X with ROM v1.90, so that freeze in your 39001 console is expected.

Regarding your slim console, is black screen displayed even when launching ULE by holding :but cir:? OpenTuna defaults to OPL 1.0.0 when no key is hold, so please delete any OPL configuration file in MC or USB pendrive if plugged in, and try again.
I'd be interested in an answer as well @chronoss.
Sorry averyone, i sell my console so i cant do anything for now. Sorry sorry, i came to late
 
Thank you all.

This is working great in a SCPH-70012, that was a weird modchip that seems to prevent FreeMcBoot from working. To make even worse, seems that the dvd don't work, probably because of mechacon since this model has alot of that problem.

I configured OPL and popstarter and now my friend is so happy to have his PS2 working again.
 
Hi, sorry if this is not the best place, but I'm trying to compile a modified version of the payload and I'm using the new SDK, so I've been making some changes and now I'm stuck with this error:
Code:
mips64r5900el-ps2-elf-gcc -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -O2 -o payload.elf main.o payload_elf.o -L/usr/local/ps2dev/ps2sdk/ee/lib -Wl,-zmax-page-size=128  -nostartfiles -Wl,-Ttext -Wl,0x20c020c0 -Wl,--gc-sections
/usr/local/ps2dev/ee/lib/gcc/mips64r5900el-ps2-elf/11.1.0/../../../../mips64r5900el-ps2-elf/bin/ld: /usr/local/ps2dev/ee/lib/gcc/mips64r5900el-ps2-elf/11.1.0/../../../../mips64r5900el-ps2-elf/lib/libc.a(lib_a-crt0.o): in function `ctors':
(.text+0xfc): undefined reference to `main'
collect2: error: ld returned 1 exit status

I know OpenTuna was made with the old SDK in mind and even if it compiles it may not work but I'm willing to try anyways lol.

If anyone has any suggestion on how to fix that error I'd appreciate it, I'm completely lost :/

Edit: the only changes I made were for the files it loads from the MC and I pointed to the new SDK in the makefile, that was it.

Edit 2: I built the SDK on Ubuntu 20.04 and it's been working fine for other projects
 
Last edited:
Hi, sorry if this is not the best place, but I'm trying to compile a modified version of the payload and I'm using the new SDK, so I've been making some changes and now I'm stuck with this error:

I'ts good to know you're customizing payload, OpenTuna was built with that spirit in mind.

I know OpenTuna was made with the old SDK in mind and even if it compiles it may not work but I'm willing to try anyways lol.

Certainly It was built with an old SDK. Nonetheless, it can be compiled with newer SDKs by properly modifying Makefiles, and it should work, but personally I've not tested. Main challenge is icon tuning which is a pain in the ass. Attached OpenTuna payload sources compile with new SDK, feel free to build your own icon and please keep me up to date of that process, contact me again if you need further help.
 

Attachments

I'ts good to know you're customizing payload, OpenTuna was built with that spirit in mind.



Certainly It was built with an old SDK. Nonetheless, it can be compiled with newer SDKs by properly modifying Makefiles, and it should work, but personally I've not tested. Main challenge is icon tuning which is a pain in the ass. Attached OpenTuna payload sources compile with new SDK, feel free to build your own icon and please keep me up to date of that process, contact me again if you need further help.

Thanks! Will try your sources and see, I modified the makefiles for the new SDK but I guess I didn't do everything right, I'll keep you updated!

Edit: I checked your makefiles and they're identical to mine, so that doesn't seem to be the issue. Maybe my SDK is badly built, I may try to re-build it and see
 
Last edited:
Thanks! Will try your sources and see, I modified the makefiles for the new SDK but I guess I didn't do everything right, I'll keep you updated!

Edit: I checked your makefiles and they're identical to mine, so that doesn't seem to be the issue. Maybe my SDK is badly built, I may try to re-build it and see
I forgot to mention I modified main.c in both exploit and launcher-keys as well. In new SDK entry points to __start instead of _start. And for main.c in launcher-keys I re-defined two weak functions to reduce exploit size.
 
I forgot to mention I modified main.c in both exploit and launcher-keys as well. In new SDK entry points to __start instead of _start. And for main.c in launcher-keys I re-defined two weak functions to reduce exploit size.
Oh ok I didn't check the .c files, I'll merge your changes to mine and see, it will probably do the trick. I'll update later, thanks!
 
Oh ok I didn't check the .c files, I'll merge your changes to mine and see, it will probably do the trick. I'll update later, thanks!

Please consider these new sources, which work in emulator when payload.bin is embedded into hacked icon. Despite emulator throws false positives, just by adjusting return address repetitions it should work on real hardware, this is the cumbersome part.

Past exploit sources lead to a hacked icon that hangs console on black screen. So don't consider them.

In this new sources I'm using some novel SDK features to allow usage of KERNEL_NOPATCH and NEWLIB_NANO
 

Attachments

Last edited:
Great, thanks! I re-built my SDK and now the project compiles fine, it was my faulty SDK. Now I'll try building with my changes and see if the exploit works.
 
Well I got the payload and the installer to compile, now I get a corrupted OSDSYS after excecuting the exploit. According to your documentation I probably need to increase the return address repetitions, unluckily I didn't understand how to do it. If you could explain it in more detail I'd really appreciate it.

Also, does the exploit use address 0x20C020C0 or 0x20B020B0 as the documentation says?

Edit: I'm testing on real hardware btw, a SCPH-79001 to be precise

Edit 2: My doubt regarding the repetitions is, do I just modify the multiplier (in the example 7FF0 and 7716 values) or do I need to do something else?
 
Last edited:
Also, does the exploit use address 0x20C020C0 or 0x20B020B0 as the documentation says?

OpenTuna v1.0.2 uses 0x20C020C0 as return address, 0x20B020B0 is for v1.0.1 which is no longer used in sources just in documentation. So, stick to 0x20C020C0.

Edit: I'm testing on real hardware btw, a SCPH-79001 to be precise

Nice, I've got that one too.

Edit 2: My doubt regarding the repetitions is, do I just modify the multiplier (in the example 7FF0 7716 values) or do I need to do something else?

That's the tricky part, sorry I have not automatize it. Anyway, if you want, send me icon.icn and I'll give some tips about how to tune it. Be sure payload-packed.elf properly works before trying to tune icon.
 

Similar threads

Back
Top