Messages

46

Reverse Engineering / SceCompat - Trick to write to the MIPS Reset Vector

« on: April 12, 2020, 01:47:23 PM »

I was watching that PSP Homebrew conference thing and thought the ME processor accelerating Minecraft from 15fps to 60fps was cool.

So I thought it'd be cool to do something similar with the Vita with the MIPS processor.

However, it seems TheFlow has achieved this (https://github.com/TheOfficialFloW/VitaMips). But I'll just document this if it hasn't been documented already:

The idea was to write to the MIPS reset vector as was done in the ME example Motolegacy linked (https://github.com/pspdev/pspsdk/tree/master/src/samples/me).

The reset vector should be the first thing that is executed by the processor, which before command 0x30006, is held in SceCompatSharedSram.

Normally, if you try to peak at the SceCompatSharedSram, it will cause a crash until command 0x30006 on compat_sm.self is called. However, on accident by putting the wrong amount of arguments on a hook, I found that passing 0 size on 0x10006 allows you to write to the reset vector once through some f00d glitch. Maybe I'm wrong, try for yourself.

This was tested on 3.60.

To prove this theory:

• A hook is made set the 0x10006 command to fail with 0 size on SceCompat
• This hook will then read "ux0:/data/mips_rst.bin" to the reset vector. I will attach the the pre-ipl + challenge mips_rst.bin to the post.
• Adrenaline is then loaded (it seems to only work once for Adrenaline?) with the mips_rst.bin loaded into the Reset Vector.
• Adrenaline is then loaded without  mips_rst.bin, causing error c1-2650-3
• Adrenaline is then loaded with the continue commented out, which causes kpanic.
• Change the hook to pass the size, and it should crash.
• Uncomment write_reset_vector(); in the standalone func, it should crash.

https://gist.github.com/dots-tb/0357e1a66db98e81153d0e8204ffce64

I will be posting more findings relating to SceCompat if they are not already documented.

Thanks to Mathieulh for his Wiki information, Motolegacy for linking the ME example, Celesteblue and Princess of Sleeping for being fappers and helping a ton, teakhanirons, and Sysie for method of testing

TheFlow for adrenaline.

Anyways, in what has become standard for me, I just found this and have no idea how it works. Hopefully, someone will find it useful.

47

General / [Archive] Native Resolution for PSP games on PSVITA [UPDATE]

« on: April 07, 2020, 09:43:56 PM »

This post was originally made by SuperiorSpidy to /r/vitahacks, I was surprised when I went looking for it and it was missing. Luckily it was archived on removeddit and I had a link in my phone history. I am archiving it just in-case some of you have missed it:

robots commented 10 hours ago • edited

So, since this corona stuff, work is being relaxed. I think i will have time to work on this.

I have created repository, and pushed all my stuff into that. I cannot push my notes there as they are in my head :-)

robots/Adrenaline@a0b1b68

Description:psp part: this is copied and reworked uofw ge driver. All writes and reads from registers have been replaced by requests to vita.

https://github.com/robots/Adrenaline/blob/master/cef/systemctrl/ge-vita.c#L78

PSP ge driver is source:https://github.com/uofw/uofw/tree/master/src/gewith my additions (hopefully fixes):https://github.com/uofw/uofw/pull/58/files

Since there is limited number of shared resources between vita and psp, we have to share. There is at least one messagebox free (KERMIT_MODE_EXTRA_1, adrenaline uses KERMIT_MODE_EXTRA_2). But these are no interrupts free. We will share the interrupt adrenaline uses. Adrenaline uses this only to signal save/load of state and memory card reinsert - these are very rare interrupts, thus Adrenaline will not mind sharing.

u/NT-Bourgeois-Iridescence-Technologies it is not possible just to stream gpu data from psp. Gpu data is in ram that is not accessible from vita.

I patch the sceGeEdramGetAddr function to return address in vita's CDRAM (mapped into PSP's memory space) This way PSP game will write directly to shared memory. This makes it harder to have both gpu on vita, and ge on psp work at the same time (i would like to have switch, for games that are not yet compatible, but i am sure we can unpatch the ge driver or add some flag to select code.)In psp code i think it misses just the hooking stuff (and the flag)

For the vita part, i have started to write the GE state machine in C. I use PPSSPP's gpu framework as source of ideas. But its like 2percent of work done.

The roadmap should be something like:

write vita's ge statemachine
test it on vita only (with some psp example from https://github.com/pspdev/pspsdk/tree/master/src/samples/gu)
finish psp ge driver hooking.
test complete system.
So what is needed is one PSP developer who knows psp hooking stuff to finish the ge driver.

Source:
Archive: https://www.removeddit.com/r/vitahacks/comments/fwnj5f/native_resolution_for_psp_games_on_psvita_update/
Original: https://www.reddit.com/r/vitahacks/comments/fwnj5f/native_resolution_for_psp_games_on_psvita_update/

Mirrors:
https://github.com/dots-tb/Adrenaline
https://github.com/dots-tb/uofw

Edit:



It seems that the /r/vitahacks mods have deleted it... No one is safe from them.

48

Reverse Engineering / Re: Bruteforcing NIDs on the PS Vita

« on: April 05, 2020, 03:11:24 AM »

I thought of something else, since the no name suffix is only used for exports without a library name, that would infer that the suffix is generated from the library name in an unknown fashion.

49

Reverse Engineering / Re: Bruteforcing NIDs on the PS Vita

« on: April 02, 2020, 09:23:45 PM »

Further info:
Regarding the unknown suffixes, certain properties can be discerned:

We know from modules like SceNpDrm the dbg_fingerprint (or module NID in some non-updated documentation) can change, with functions within it staying the same. Celeste has told me that this is a hash used for versioning.

See:
https://wiki.henkaku.xyz/vita/Modules#Structure
https://wiki.henkaku.xyz/vita/SceNpDrm


The hashing algorithm for this can be found within the official SDK, however we have not confirmed if this is the same algorithm used by Sony internally. It is very likely that it is.

When a module is updated, it doesn't necessarily mean that the suffix will change. We know that certain modules with added features will maintain their NIDs for the syscalls. (Need to check for the libraries).

All Library NIDs get updated per a module, when this happens, the syscall NIDs also get updated? (Need to confirm).

50

PS Vita / Re: [Release] Sharpscale - native 960x544 HDMI output for PSTV

« on: April 02, 2020, 07:18:56 PM »

https://twitter.com/CBPS9/status/1245758302925062145


Regardless, very nice work cuevavirus!

51

Reverse Engineering / Bruteforcing NIDs on the PS Vita

« on: April 02, 2020, 04:37:43 AM »

Some information pertaining to bruteforcing NIDs on the PS VITA:

The algorithm would fall into two categories:

Category 1: The system used on the PSP was just a sha1 hash with the first few bytes selected and then byte swapped, there are a few libraries that follow this scheme on the PSV

Example:

sha1(ScePowerForDriver) is equal to:

Code: [Select]

6F16901583C1DFE13731A51CFD2B528845256D2D
The library nid is the following:

Code: [Select]

0x1590166F
So then, with a quick check, I found that the following libraries can be easily bruteforced with this method:

Code: [Select]

SceDisplayForDriver
SceFace
SceFios2KernelForDriver
SceIdStorageForDriver
SceLedForDriver
ScePower
ScePowerForDriver
SceSmart
SceVoice
SceVoiceQoS
This means that any syscall within these libraries can be bruteforced with just sha1. Many of the names are shared with the PSP, however they have been already bruteforced.

I think there is another library called something along the lines HPRemote that can also be bruteforced, with most of the known ones being added to the henkaku wiki using this method.

I have also found that modules compiled with the official SDK also use this:

sha1(mono_profiler_install_code_chunk_new)

Code: [Select]

5bd0d709bda4fc415a90380f1990d51ecea56eee
The functions nid:

Code: [Select]

0x09D7D05B
Thus, every module included in official games can have their function names bruteforced as long as they actually are exported. Ex: Unity modules and the modules included with PSO2.

You CANNOT bruteforce function names that are not exported such as internal functions or any function within the main eboot. This is how the mono NIDs I had posted earlier were found.


Category 2: These NIDs have a suffix which is concatenated to the end of the name before they are hashed. The methodology of obtaining these generating these suffixes are yet to be found.

However, we do have an example of one suffix:

Code: [Select]

c1b886af5c31846467e7ba5e2cffd64a
Found here: https://playstationdev.wiki/psvitadevwiki/index.php?title=Keys#NID_generation_suffixes

This specific suffix is used in generating function NIDs for functions with no library, such as module_start:

module_start + suffix (binary data) as hex:

Code: [Select]

6D 6F 64 75 6C 65 5F 73 74 61 72 74 C1 B8 86 AF 5C 31 84 64 67 E7 BA 5E 2C FF D6 4A
Yields the results:

Code: [Select]

96D15C936510321C7D607B4DFC06BC73063E2561
The actual NID is:

Code: [Select]

0x935CD196
It is theorized that the majority of NIDs are generated using a suffix, however, again, the methodology of generating this suffix is unknown.

Special thanks to CelesteBlue and Princess of Sleeping.
Further thanks to SocraticBliss and ChendoChap for working on a hashcat bruteforcer, and SilverSpring.

52

Tutorials / Re: Compiling xerpi's PS2 emulator Play!

« on: April 01, 2020, 10:36:29 PM »

Here is a precompiled binary.

Edit:
Further instructions:

• Install the VPK
• Download http://www.billhung.net/3d/ps2/teapot/teapot.elf
• Rename it to "cube.elf" and put it in"ux0:Play"

53

PS Vita / MOVED: Compiling xerpi's PS2 emulator Play!

« on: April 01, 2020, 10:33:07 PM »

This topic has been moved to General.

https://forum.devchroma.nl/index.php?topic=109.0

54

PS Vita / MOVED: [Tutorial][Windows] VS Code with VitaSDK

« on: March 30, 2020, 02:37:30 AM »

This topic has been moved to Tutorials.

https://forum.devchroma.nl/index.php?topic=95.0

55

Reverse Engineering / Re: SceShell Notice

« on: March 24, 2020, 07:31:36 AM »

Very nice!

56

PS Vita / Re: Performing a PS Vita UART Mod

« on: March 02, 2020, 06:06:01 AM »

Code: [Select]

void putchar_sub(int args, char *c) {
ksceUartWrite(0, c);
}

int init_uart_test() {
printf("kscePervasiveUartClockEnable %x\n:", kscePervasiveUartClockEnable(0)); // Turn on clock
printf("kscePervasiveUartResetDisable %x\n", kscePervasiveUartResetDisable(0)); // Out of reset
printf("ksceUartInit %x\n", ksceUartInit(0));
printf("kscePervasiveUartSetBaudrate %x\n", kscePervasiveUartSetBaudrate(0, 115200));

ksceKernelDelayThread(100000);
ksceUartWrite(0, 'h');
ksceKernelDelayThread(100000);
ksceUartWrite(0, 'e');
ksceKernelDelayThread(100000);
ksceUartWrite(0, 'l');
ksceKernelDelayThread(100000);
ksceUartWrite(0, 'l');
ksceKernelDelayThread(100000);
ksceUartWrite(0, 'o');

ksceDebugRegisterPutcharHandler(&putchar_sub, 0);
}
This is the code I used to test stdout on uart. However, you could probably can properly enable it by looking at sysmem's start up which has mechanisms to enable it. I didn't really need it so I never looked into it.

You could also probably put ksceUartWrite directly into ksceDebugRegisterPutcharHandler.

Teakhanirons asked for this so I decided to post it.

57

Tutorials / [Tutorial][Windows] VS Code with VitaSDK

« on: February 16, 2020, 03:44:42 AM »

What is VS Code?:

SonicMastr told me to try VS Code again...

Visual Studio Code is the latest meme/botnet code editor from Microsoft that everyone is using to program now. It is similar to Visual Studios in allowing IntelliSense except more lightweight, cross-platform, and in an attempt attract neck beards to this botnet, offers more customization.

IntelliSense in action with VitaSDK (Code Auto-completion)



IntelliSense in action with VitaSDK (Code Parameter Information)




Of course, with this demographic comes the emulation of annoying configuration that doesn't work out of the box in order to give feed into a superiority complex that these neck beards so desire.

What Will This Tutorial Cover?:

This will be a brief overview on getting VS Code to work with VitaSDK installed through msys2 on Windows. This includes building and setting up the headers. This is just what worked for me and may not apply to your system (ex: if you are using a dated 32 bit machine). I don't really know how to use this thing, so I'll just tell you everything I had to do.

You will need:

• https://code.visualstudio.com/
• https://www.msys2.org/
• https://vitasdk.org/
• A project to build.

Installing msys2 and VitaSDK:

Since they have detailed steps on their respective websites, I will just give notes on installing. If you already have it installed, make sure you have the dependencies listed below.

Install msys2 first, downloading the 64bit version (ex: msys2-x86_64-*.exe). Install it then SCROLL DOWN and follow the remaining instructions on the website!

Then attempt to install VitaSDK through the Windows instructions on their website, except use the following dependencies instead:

Code: [Select]

pacman -Su make git cmake tar mingw64/mingw-w64-x86_64-libwinpthread-git python mingw-w64-x86_64-cmake mingw-w64-x86_64-toolchain
For doing exports, if you don't know where the .bashrc file is:

Code: [Select]

nano ~/.bashrc

This will open a text editor, paste the export information into there and restart your terminal.

After this, continue with the install of vdpm and hopefully it will work for you...

Make sure the following is in your Windows User PATH environment variable. I cannot give instructions for this since it is different for every version of Windows, a quick google search will tell you how to do this:

Code: [Select]

C:\msys64\mingw64\bin
C:\msys64\usr\local\vitasdk\bin


Setting up a Project (Part 1):

Install and open VS Code.

Drag and drop the source folder of the desired project onto VS Code.

By source folder, the directory that contains the CMakeLists.txt file.

VS Code should automatically detect and prompt you to install the CMake Tools and C/C++ extensions by Microsoft.

If not, click on the Extensions button on the left side bar, search for C/C++ and CMake Tools (not CMake) and install them respectively (I already have them installed).



After both extensions are installed, it is now time to configure CMake Tool. Because CMake defaults to Unix Makefiles and Windows obviously does not use a Unix file system, errors will occur. Thus, the following section is dedicated to fixing this issue by using minGW, which uses Windows Paths. I think...

Hit the key combo CTRL+SHIFT+P to open the "Command Palette" and type Settings json and look for "Open Setttings (JSON)"



Add the following to your settings.json:

Code: [Select]

    "cmake.buildDirectory": "${workspaceRoot}/build/${buildType}",
    "cmake.configureOnOpen": true,
    "cmake.cmakePath": "C:\\msys64\\mingw64\\bin\\cmake",
    "cmake.generator": "MinGW Makefiles"

By doing this, we are changing the CMake generator type to MinGW to allow it to build within windows and we are using the MingW64 cmake. The rest is maybe optional. I don't know.

Be sure you have all your commas and keep the syntax proper.

Example settings.json:


Now open the Command Palette again, and type "cmake" and look for "Edit User-Local CMake Kits"



Add the following code to the now opened cmake-tools-kits.json:

Code: [Select]

  {
    "name": "VitaSDK",

    "toolchainFile": "C:\\msys64\\usr\\local\\vitasdk\\share\\vita.toolchain.cmake",
    "preferredGenerator": {
      "name": "MinGW Makefiles"
    },
    "environmentVariables": {
      "VITASDK": "C:\\msys64\\usr\\local\\vitasdk",
      "CMT_MINGW_PATH": "C:\\msys64\\usr\\local\\vitasdk\\bin"
    }
  },
With this config, we are setting the VitaSDK enviromental variables along with setting the path to locate the compiler binaries. We are also hard-coding the location of the toolchain cmake file (normally set by the cmake file in the project).

Be sure to mind your brackets, commas, and curly braces.

Example cmake-tools-kits.json:



Make sure you saved all your files and now CMake should be configured.

Look at the bottom left corner of the Window, you should see "No Kits Selected", click on that and change it to "VitaSDK".



You should be able to build now by clicking the "Build:" button in the same bottom bar area.

If it doesn't work the first time:

• Navigate to the location of the source folder and look inside it.
• Make sure there is no build folder.
• Open the command palette and then type Developer Reload and reload the window

And with luck, it should configure CMake and allow you to build the project.

Setting up a Project (Part 2):
You will have to do the following with every new opened project.

Open the command palette, then type c++, looking for "C/C++: Edit Configurations (UI)"


Add a new configuration called VitaSDK and set the compiler path to the following:

Code: [Select]

C:\msys64\usr\local\vitasdk\bin\arm-vita-eabi-gcc.exe



Scroll down and un-collapse Advanced Settings then look for and set the Browse Path to the following:

Code: [Select]

C:\msys64\usr\local\vitasdk\arm-vita-eabi\include



This should set up IntelliSense.

The nightmare is over and now you can enjoy using VS Code. You can try setting up other things like Davee's gdb thing, but it is not as stable as I would like it to be.

If you need help: https://discord.cbps.xyz

58

N GBA / Re: Some iQue GBA Prototype games

« on: February 05, 2020, 02:33:59 PM »

MD5 for files:

Advance_Wars  陆海空大战  高级战争
C5BE1188D3ED703A50426C4D552B469F - ADVANCEWARS_AWRC00.gba

Densetsu_no_Stafy  斯塔非传说  传说的斯塔非
38856F86A30538CBB3E4164DA96002A7 - STAFY_ASTC00.gba

Densetsu_no_Stafy2  斯塔非传说2  传说的斯塔非2
8DC9EB3C6A76FE563BDD7B7D10F2B72C - STAFY_2_AVFC01.gba


DK_King_of_Swing  摇摆森喜钢  大金刚摇摆之王
064DB81169E3CB761C5702260039AE28 - BURABURADNKY_BBKC00.gba

Famicom_Mini_Collection  红白机合集
064DB81169E3CB761C5702260039AE28 - _FICC00.GBA

Fire_Emblem  火纹战记封印之剑  火焰之纹章封印之剑
CD5C952CCF9A78915CBEFEC0FECF241D - FIREEMBLEM6_AFEC00.gba

Kuru_Kuru_Kuruin  转转棒  咕噜咕噜滚滚棒
93539207BE7D05E2EF8E3E9B44A82C2E - KURURIN_AKRC00.gba

Kuruin_Paradise  转转棒天堂
43849ED3425271E56E183D6B6999DFB7- KURUPARA_A9QC00.gba

Mario_Kart_Super_Circuit  马力欧卡丁车超级赛道 马里奥赛车超级巡回赛
54A1EA59C39FF418AF3B009CD1ECC6D6 - MARIO_KART_AMKC00.gba

Mario_Luigi_Super_Star_Saga  马力欧与路易吉RPG
54AC1DEF7820BEED364A38EDB65E22F0 - MARIO_LUIGIJ_A88C00.gba

Polarium_Advance  通勤一笔
76E7DAC53DB04F2B4FBC792659954C7D - HITOFUDEGBA_BIIC00.gba

Tomato_Adventure  番茄大冒险  西红柿王国大冒险
70A33B660D40FAEB7B43766CEA189030 - TOMATO_ADV_AGLC00.gba

59

PS Vita / Re: [Release] reScreeny - screenshots in folders that make sense

« on: February 02, 2020, 08:42:04 PM »

reScreeny v1.2 Update:
An issue with multiple spaces preceding and trailing a file name would cause issues such as with Superdimension Neptune VS Sega Hard Girls.

This was fixed and reported by xdanieldzd
https://github.com/dots-tb/reScreeny/releases/

Thank you.

60

Reverse Engineering / [Tutorial] Decompiling a Vita self

« on: January 27, 2020, 02:10:54 AM »

This tutorial will go over the basics of decompiling a vita binary in the self format. Xerpi has made a pretty good readme, but this tutorial was requested.

You will need:

• FAGDec by FAPS or sceutils by Team Molecule*: https://github.com/CelesteBlue-dev/PSVita-RE-tools/tree/master/FAGDec/build
• vita-unmake-fself by FAPS: https://github.com/CelesteBlue-dev/PSVita-RE-tools/tree/master/vita-unmake-fself/release
• Ghidra by NSA and Tax payers like you: https://ghidra-sre.org/
• GhidraVitaLoader by xerpi: https://github.com/xerpi/GhidraVitaLoader
• yamlbeans by Esoteric Software(?): https://github.com/EsotericSoftware/yamlbeans/releases
• db.yml in VitaSDK: https://raw.githubusercontent.com/vitasdk/vita-headers/master/db.yml

*sceutils requires more setup and will probably be covered in another tutorial, so we will use FAGDec in this one, assuming that your firmware can handle the modules you wish to decompile.

Using FAGDec to obtain a specimen.
This is a must do step because most modules are encrypted and cannot be directly decompiled. You may skip this if you know how to use sceutils by Team Molecule

After downloading the VPK from the PSVita-RE-tools repository and installing it using Molecular shell/Vitashell, open it.

FAGDec will then list all common devices (ux0, vs0, and os0) and the games it has found. Click on any of these options to bring up a list of decyptable assets. It will take a while to search for all assets, wait for the DECRYPT ALL to say (DONE).

The home screen of FAGDec listing all common devices and games:



FAGDec currently searching for modules:



FAGDec when it is done searching for modules:



Scroll and find the desired module adding it to the list on the right.

Go back to the main menu and select either "Decrypt to ELF" or "Decrypt to SELF".

If you decrypt to SELF (in some cases such as using elf-injector this is desired: https://github.com/CelesteBlue-dev/PSVita-RE-tools#vita-elf-inject-usage), you must run though vita-unmake-fself. This can be done through command line, or on windows, just drag and drop your self on the application's executable and a elf will appear in the directory.

In the case of an ELF, you may use this directly with your decompiler of choice.

There is a more detailed guide on FAGDec available here: https://github.com/CelesteBlue-dev/PSVita-RE-tools#fagdec-usage

Note for modders, at the current time, YOU NEED SELF_AUTH.BIN. Please do not forget to include this file.

Your files will decrypt to "ux0:FAGDec"

Setting up GHIDRA:
Download Ghidra and extract the zip file.

Download and place the yamlbeans jar in the root Ghidra folder that contains "ghidraRun".
Download and place the VitaLoader.java in the same place as above in a folder called Scripts (create this folder).
Download and place the db.yml in the Scripts folder.

Run Ghidra by double clicking ghidraRun.bat

Go to Edit > "Plugin Path..."

Hit "Add Jar..", navigate and find the yamlbeans jar adding it to the list.



Create a New Project (File > New Project) that is not-shared.

Go to File > "Import File..."
Navigate to the ELF and import it. It should auto-detect the ELF type, press OK to both pop ups.

Double click the file in the list.

If you get a prompt asking to analyze the file, hit Yes. Then in the following prompt hit Analyze.

Be aware that on big files this may take a while. There is a status indicator in the bottom right. You may need to resize your window to see it.



Go to Window > Script Manager

Click on the Script Directories button (1. in the image) and then click on the add button (2. in the image).

Navigate to the Scripts folder containing VitaLoader.java. Then click OK.



Hit Dismiss. Refresh the scripts (3. in the image).

VitaLoader is now set up in Ghidra.

Running VitaLoader.java

These steps will have to be repeated for every new loaded vita ELF.

Go to Window > Script Manager (If you are not already in it)

Scroll down on the folder list until you find Vita. Click it.

Make sure VitaLoader.java is checked and double click it. It will now open a file open dialog, this is for the db.yml in order to resolved the NIDS/Syscalls.



Navigate to the Scripts folder and open the db.yml.

If no errors occur, then you can now examine the elf.