PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

164w ago - This weekend PlayStation Vita developer wololo has made available a guide to porting VHBL (PS Vita Half-Byte Loader) to individual game exploits for those interested.

This news comes proceeding the recent Motorstorm Arctic Edge and Everybody's Tennis PSP / PS Vita game exploits.

Below is the guide, to quote from his blog (linked above): This guide assumes that you found a user mode exploit in a game, and that you were able to write a binary loader.

So now what’s next? Well, as you probably know if you’ve gone that far, the PSP scene doesn’t really like “hello worlds”. A hello world is nice, but it accomplishes nothing, it just draws Sony’s attention to your exploit, and you know the vulnerability will be patched soon, while nobody really used the exploit.

Well, the next step is, ideally, a HEN or a custom firmware. Of course, this requires a kernel exploit, and we know how these are difficult to find. A much more doable task, that will make lots of people happy, is to port HBL to your exploit. HBL opens the door to lots of legal contents on the PSP and the Vita, and we designed it so that porting it to your game exploit can be done fairly easily.

This tutorial is valid at the time of its writing, for all games, and up to firmware 6.60 (Vita firmware 1.61). In theory, HBL will work on future firmwares, but of course new kinds of security might be introduced in new firmwares. Additionally, depending on your game (and its function imports), the compatibility and speed of homebrews might vary.

0. Easy as pie

HBL was designed to be easily ported to new game exploits. Most Game-specific files (except one) go in a subfolder that I will describe below. To complete this tutorial, you need basic shell skills, a working pspsdk, a working game exploit and the associated binary loader / hello world, a ruby interpreter, and basic ruby skills (usually, if you know any other scripting language, you’ll figure it out easily, there are not so many changes required).

1. Get the HBL sources and compile them

The first step is to get the HBL sources, compile them, and if you’re motivated, test them on an existing game exploit, to make sure the copy you have works correctly. (As I write this, it is recommended to test compilation with either the Mototrstorm or the Everybody’s tennis exploits, as we might have broken backwards compatibility with older exploits)

The sources of HBL can be downloaded here (SVN client required: http://code.google.com/p/valentine-hbl/source/checkout)

In order to compile it, you need the PSPSDK (which you probably already have if you wrote a binary loader). Compilation is fairly easy, but in order to compile the HBL for a specific exploit, you have to specify the folder of the exploit. for example, make FOLDER=lifeup will compile HBL for the Motorstorm (EU) exploit.

2. Create your own exploit’s folder

As you guessed, you will create a folder dedicated to your own exploit. Let’s imagine you game is called wololo, then you can create a subfolder “wololo” in the eLoader folder. Basically, we want to reproduce the files that are in this folder for another exploit, and adapt them to our exploit. Let’s have a look at the lifeeu folder:

The folder contains 6 files and 1 folder (which contains 1 file) that you will want to adapt to your exploit. I will describe each of them separately. Most of these files are automatically generated by a script, so this should be fairly simple.

3. Create your exploit’s files

linker_loader.x

This is the linker file for h.bin. If you created a binary loader and a hello world, you already have this file from your hello world, and most likely you named it “linker.x“. Copy linker.x from your hello world to linker_loader.x. Done!

sdk_loader.S

This is the sdk for h.bin. If you created a binary loader and a hello world, you probably already have this file, and named it sdk.S. Copy sdk.s to sdk_loader.S. If you don’t have this sdk, you can create it either by running prxtool on the EBOOT.BIN of the game, or by using the moskitool (a ruby version of the moskitool can be found in the eLoader/tools folder of the HBL). Most likely, if you created a hello world, you already have this file so I won’t give more details for now. Done!
config folder, exploit_config.h, sdk_hbl.S, loader.h,

The contents of the config folder, as well as sdk_hbl.S, loader.h, and most of exploit_config.h (details below for exploit_config.h) are automatically generated by a ruby script that you can find in eLoader/tools/gen_exploit_config.rb.

The gen_exploit_config.rb has 2 “modes”, but I will only describe the first one, which is required the first time you adapt your exploit. You need to have a usermem dump named memdump.bin (that you acquired from psplink with the command savemem 0x08800000 0x01800000 memdump.bin). Important note: For Vita compatibility, that dump must be done on a PSP running firmware 6.60. In addition to memdump.bin, you need a list of UIDs from the same psplink session, that you will name uidlist.txt.

You can get that file by typing uidlist > uidlist.txt in psplink. That file needs to be in unix format, so be sure to convert it if you are running windows. Finally, you need a file named sdk.S, which is nothing else than the sdk.S you created for your game exploit, the one we just named sdk_loader.S above.

Put these 3 files (memdump.bin and uidlist.txt obtained from the same psplink session, as well as sdk.S from your exploit) in the tools folder, and run gen_exploit_config.rb

This should display a list of addresses (you will want to copy these addresses inside the stubs array of gen_exploit_config.rb so that other people who want to improve your exploit won’t need a memory dump/uidlist anymore, although they will still need the sdk.S file), and generate a series of files in the tools/output subfolder.

The files generated by gen_exploit_config.rb in the output folder can be copied “as is” into your game’s folder.
Final edits to exploit_config.h

You’re almost done, but the file exploit_config.h need to be edited in two places, that you will find because they say “TODO” in big letters.

HBL_LOAD_ADDRESS This is where you will load HBL in RAM. You want a value that is outside of the boundaries of the game, and basically, a place where the PSP will accept to alloc roughly 200kB. you can get such an address in psplink while the game is running by typing malloc 2 test l 204800

HBL_ROOT is the name of the folder where your exploited savedata is. That folder name looks like ms0:/PSP/SAVEDATA/UCUS12345000. Important note: my tutorial on how to create a binary loader assumes you will load a file named ms0:/h.bin. On the PS Vita, this is not possible anymore, so you will have to adapt your binary loader in order to load the exploit from ms0:/PSP/SAVEDATA/XXXXXXX/h.bin (where XXXX is the folder of your savedata). In the Vita version of HBL, all HBL files for in that folder, and there is no subfolder.

linker_hbl.x

copy linker_loader.x into linker_hbl.x, and replace the address value with the value of HBL_LOAD_ADDRESS that you figured out earlier while creating exploit_config.h. Done.

4. Compile

  • Run make FOLDER=yourfolder (alternate ways: make distrib FOLDER=yourfolder to remove debug messaging, make nonids FOLDER=yourfolder to remove NIDs-related heavy debug messaging)
  • You’re done, grab the h.bin and hbl.bin in the root, the config folder from your exploit’s folder, and the libs_… folders from the root. You now have the meat of your HBL port ready.

5. Last but not least

HBL is licensed under the GPL. If you plan to distribute your compiled binaries, it is required that you provide your source code as well. Don’t make us ask for it

This tutorial is voluntarily vague. Porting HBL is fairly easy, but we assume that if you made it that far, you probably are skilled enough to do some research on your own. Nevertheless, don’t hesitate to ask questions if you are running into problems

You are allowed to reproduce this article on other websites and/or translate it on condition that you put a clear link to this page in your copy.

6. More details

Porting VHBL is simple in theory, but many games do not import some functions that are necessary for HBL to run properly. One goal of the script gen_exploit_config.h is to analyze the imports of your game (this is why the sdk.S is necessary), and define some workarounds in exploit_config.h in case your game does not have all the necessary exports. This should work in most cases, but that script is still experimental and might make mistakes. Below are a few details on some of the “define” sections it creates:

TH_ADDR_LIST, EV_ADDR_LIST, SEMA_ADDR_LIST, and GAME_FREEMEM_ADDR can be computed for you by the tool eLoader/tools/freemem.rb. For that you will need a memory dump and a file uidlist.txt which is the output of the uidlist command in psplink (uidlist > uidlist.txt ). It is important to note that the memory dump and the uidlist need to be from the same session, otherwise the addresses will be incorrect. If you’re on windows, also make sure that the uidlist.txt file is in the unix format (use your favorite editor to convert it if needed). For those interested, here are some technical details about those variables, but basically the tool should do it for you

TH_ADDR_LIST, is the list of threads you want to kill. Threads are defined by a SceUID, but since this value changes all the time, what we actually want is the addresses where they are defined. in psplink, while your game (or your hello world) is running, you can get a list of these thread by typing thlist. Then look for each thread’s uid in ram. The address (hopefully unique) where the thid is defined, is what you want to put in this list.

EV_ADDR_LIST is the list of events you want to kill. You get this list by typing evlist in psplink. The rest is similar to the construction of TH_ADDR_LIST

SEMA_ADDR_LIST is the list of semaphores you want to kill. You get this list by typing smlist in psplink. The rest is similar to the construction of TH_ADDR_LIST above

GAME_FREEMEM_ADDR this is the address in Ram where the game’s memory was allocated. Most game have this but for those that don’t have it (patapon2), this value can be commented out. To find this value, type uidlist” PSPLink and look under the SceSysMemMemoryBlock section. You’re looking for blocks that have a 0xFF (user) attribute (not 000!), and are not “stack”. In the golf exploit, this block was simply called “block” and was easy to find. Again, you’re interested in the entry address, not the uid.

UNLOAD_ADDITIONAL_MODULES : define this variable if possible. Comment it out only if you run into issues at the “free memory” stage of HBL

Other variables: The variables above are the basics of the config file. With those, HBL should basically work, or at least take you to a step where you can start debugging. But with time, HBL has grown and has been updated by several people. In order to maintain backwards compatibility and increase game coverage, the exploit_config file was added several config values.

DISABLE_P5_STUBS is useful if you run into a crash/freeze even before hbl is loaded (just after firmware detection). SYSCALL_* are used for perfect syscall estimation on firmwares where this is available (TODO: explain syscalls estimation), etc… at this point you will probably need to dig in previous exploit_config.h files in order to find more on each macro you can possibly define.


Guide to Porting VHBL (PS Vita Half-Byte Loader) Game Exploits

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew PS4 Downloads.




#111 - Nabnab - 176w ago
Nabnab's Avatar
Ok fine, i give you another python script i made but this one is different and more interesting -> Funny Hello world communication with the PS Vita Check out


#110 - Nabnab - 176w ago
Nabnab's Avatar
Hello Everybody.

Sorry i forgot to give you another python script i made (it can read some information of the PS Vita Configuration/Endpoints)

The first script = test to detect the PS Vita on Linux/MacOS/Windows without using CMA

The second script = read the configuration/endpoints information of the PS Vita (work on Linux/MacOS/Windows) just need to have pyUSB/Python to use the script.

On the second script you will have this result

PS Vita Found ! PS Vita information:
bConfigurationValue: 1
bInterfaceNumber: 0
bAlternateSetting: 0
bLength: 9
bEndpointAddress: 129
bEndpointAddress: 2
bEndpointAddress: 131


#109 - Nabnab - 176w ago
Nabnab's Avatar
I leave you a small python script i made to detect the PS Vita on MacOS/Linux/Windows (you need to have PyUSB/Python), you can test it to be sure that your PS Vita is recognized without CMA. You can also launch a PS Vita game and leave the USB Plug on (still recognized)

One problem i found about the detection of the PS Vita, you can't let the PS Vita go in Standby mode...

I found also something weird and i was wondering if some people who has a PS Vita can test ? Turn off the PS Vita (wait the end of the PS Logo blue light) Hold PS Logo button for 10sec and stay hold the button and try to turn back on the PS Vita, normaly you can't
and it has something to do with a debug USB mode, didn't find yet, i'm working on my MacOS/Linux driver PS Vita and also something else i can't talk right now (too early and too much bug)

Here is the script

I just add a picture of the command/script


#108 - cfwprophet - 176w ago
cfwprophet's Avatar
I know that forum mate !! As i has started on ACiD the very first PS3 CFW peoples started to bash me and my team and always wanted some prove or called me bad words. I'm no learned coder i do this all by my owen and learn what i need to accomplish the job. Till today i hold some mods/hacks in my private that others ps3 cfw's still don't have like a FW embeded Half-File Manager. Or on the Wii my work on the Unbrick Disks i hold some info that let peoples boot my disk's without the need of any RescueMenu hack.

Kiddyz always popping up and want some prove or try to bash. But i'll release the info when i want and not only for prove my self to others. Maybe when i get back a ps3 i'll start again and finish what i have started for over one year. Most peoples just adding hacks or code of already released stuff and try to get attention.

As i said if i finish my work and release it it will have features no one other CFW till now has beside the fact i for sure also implement already released good stuff.

With simply words: I hear you and im with you

#107 - Tidusnake666 - 176w ago
Tidusnake666's Avatar
Keep up good work, Nabnab, I once had some small ps3 games-related projects here on ps3news too, so I honestly wish you good luck. Cheers!

Also, if you want, you may open a separate thread here, where you can give details about your work / keep us up to date. Correct me if I'm wrong, plz

#106 - Nabnab - 176w ago
Nabnab's Avatar
It was me, somebody told me that a Japanese Website called emuonpsp talked about it the next day after i said it.

I told to one person what i found about the combo key few days ago but apparently he already told to somebody, i made the video 3 January (French time) and before the website emuonpsp talked about it, that's why i didn't understand what happened and i don't even know who emuonpsp is until today.

silw -> it's me... This is part of my work and my investigation on the PS Vita...

Now about combo key, I was the guy talking about the first combo key (glitch/debug/recovery) on Vita. From the beginning I was wotking on the PS vita and already explained many things about it and this one too.

Silw is just a name I have, I don't understand what's wrong with some people, I give some help, i'm showing stuff and explain how to do it and after alll You tell me it's bs, who are you to judge me, do you know my life, respect other people thanks

#105 - cfwprophet - 176w ago
cfwprophet's Avatar
Are you sure that this is of you ? I found several sources on the net they reported that this comes from an chinese site called emuonpsp and also have made available the key combo used to display that.

Japanese site emuonpsp reported today that a combination of keys was found in the settings menu to display some hidden information about the firmware installed on your Playstation vita.

This menu contains information about the system build, repository, revision,… doesn’t look like it’s super useful information for now, but still interesting I guess.

The combination to get this menu to show requires practice but I could confirm it works on my vita (Firmware 1.510).

Go to Settings > System > System Information
Press simultaneously RTrigger + LTrigger + DPad Left + Square for a few seconds
Release those buttons then immediately press the start button
tadaa, additional information shows up


ps. the vid was taken by silw no word of a Nabnab anywhere.

#104 - Nabnab - 176w ago
Nabnab's Avatar
Hi Everybody.

I made a video to show some hidden informations of the PS Vita




Still working on CMA Mac OS (also compatible with Linux) and i maybe found a way to mount the storage of the PS Vita (memory card)

#103 - Prince Valiant - 176w ago
Prince Valiant's Avatar
The advantage of Sony using PC software to try and manage things, it can easily be cracked

#102 - cfwprophet - 176w ago
cfwprophet's Avatar
Following up on his previous update, PlayStation Vita hacker wololo has shared a progress update on the PS Vita Half Byte Loader (HBL).

Additionally, Nabnab has also made available a video showcasing some hidden PS Vita information for those interested!

To quote: A quick report: I'm making some progress on porting HBL to the Vita. Although I'm sad to say that I can't get syscall estimation to work, I got some major homebrews such as Doom to run already, so overall I think it's in an acceptable shape.

Because it is roughly stable now, today I focused on porting HBL to the EU version of the exploited game (I was working - obviously - on the Japanese version of the game so far). This went smoothly and I can confirm HBL runs fine on the EU version of the game, although of course I could only test on a PSP, not on a Vita.

I used the opportunity to refresh my two guides, how to write a binary loader and how to port HBL. The guides are now simplified, and the binary loader tutorial now has download links to the tools used in the examples.

Writing the first "usable" version of HBL for the patapon exploit took several developers and about 4 months. Thanks to the portability of HBL, bringing it to Teck4′s exploit took me only a few days. Adapting that to the EU version took a couple hours (including porting the exploit itself), so I am confident for the US version.

More PlayStation 3 News...