HBL

You are currently browsing the archive for the HBL category.

Happy Birthday HBL :)  

Once in a while, I browse my old posts on this blog, to see “who I was” a few years ago. Yes, I guess I’m a kind of narcissist… One of the thing I like to do, is to see “what I posted” one year before

Most of you probably heard of Half Byte Loader for the first time around April this year, when we released a port for the Patapon2 exploit. But did you know that the work on HBL started more than one year ago, back in 2009? And that the first public release (a prototype aimed at devs only) was made in November that year, and already open source? How many of us realized at that time that m0skit0′s prototype would become such a huge part of the PSP’s hacking history? Well, if you’re interested, you can read the visionary (lol) article I wrote when HBL was first released:

http://wololo.net/2009/11/29/mooh-exploit-m0skit0s-eloader-alpha-release-devs-only/

Too bad the announcement’s source, AdvancedPSP, was taken down earlier this year :(

Total_Noob’s Hen will change the rules again, the way Davee’s chickHen changed the rules more than a year ago, but expect HBL to still be around when new firmwares show up ;)



Day 1 HBL on OFW 6.35!  

Developer Neur0n has ported HBL to OFW 6.35. Yes, HBL working on 6.35 less than 24h after the latest firmware was made available, pretty cool, uh?

Neur0n has been recently actively involved in HBL development by submitting critical bug fixes and an alternate menu, in other words he can be trusted. Although I didn’t test the exploit yet, I contacted neur0n and could confirm this wasn’t a prank.

We are still discussing the pros and cons of releasing a new version of HBL before/after TN Hen gets released. But it proves HBL still runs on the latest OFW, so we will be hard at work to release HBL for newest firmwares pretty soon.

Thanks to punker69 for the tip :)

HBL R109  

JJS Has been hard at work to improve our beloved HBL again.

As a side effect, he also fixed the issue which prevented Gpsp from going back to the HBL menu, an issue that had been here for ages.

R109 Is now also available for the “original” hot shots golf game (not the “Greates Hits” edition, the other one, see this post for more details), so people who where having trouble running the Hello world with hot shots golf can give a try to this alternate (majorly untested!!!) version.

This revision has been tested by me on a 6.20 PspGo with the Patapon2 version on the following homebrews: Wagic, T.O.M.E, Daedalus, Doom, picodrive, gpsp kai, Mobile Assault, CSPSP, Snes9xTyl, EmuMaster, ScummVM, FCE Ultra (you can download some of these homebrews from this page)

Since R107, HBL is compatible with many new homebrews, including Mobile Assault, Kurok, Half-Life (a Kurok mode), Defense Station Portable, Resonate, and many others. Join the fun and post your test reports in our forums

Download here, as usual.

Enjoy :)

Half Byte Loader R107  

Thanks to the work of JJS, J416, Neur0n, and with the help of the great community at /talk, great improvements have been made to HBL. Yes, we are aware that the upcoming Hen will change many things, but we also know that HBL remains the only way to run homebrews on new PSP models until that release, so we’re still around!

People who own Hot shots Golf 2, Everybody’s golf 2, or Minna no golf 2 will be happy to learn that we now officially support these exploits in the latest HBL revision. Due to a lack of testers on 6.30/6.31 though, we cannot guarantee that it will be as good as the experience on the Patapon2 version, but we’ll get there. Especially, we believe that the compatibility will be better with hot shots golf 2 than with Hot shots golf 1, due to the imports of the game (in particular, network).

People who run HBL on older firmwares haven’t been forgotten, homebrew compatibility has been improved, and some awesome games such as Mobile Assault or Transport Tycoon Deluxe now run on HBL!

Mobile Assault, featured on this video, can be downloaded from the developers’ website.

Thanks to developer neur0n, a bug has been fixed in the original Patapon2 exploit. This requires you to download the Patapon2 savegame once again, as usual on the HBL download page. This new savegame will most likely increase some compatibility, and I believe all other savegame exploits we have might need the same fix. We will try to fix them asap. If you are interested in the technical details behind this change, please have a look at the discussion on our forums.

We are getting less test reports than we would expect on firmwares 6.3x. Further progress on HBL on the hots shot golf 1&2 exploits directly depend on your feedback, so don’t hesitate to leave test reports on our test forums.

As you probably know, I’ve announced a while ago that we would make less releases, and release only when we think a revision is worth it. R107 is one of those. Note however that Mr X. is kindly compiling binaries usually as soon as the code gets committed to the SVN. If you’re craving for bug fixes, that’s the place to go, otherwise I suggest you wait for “official” releases such as this one.

Please note that due to personal lack of time, I was only able to test this revision on a pspgo with the patapon2 exploit, I haven’t tested any of the other binaries. If you have any issue, please feel free to ask questions here or in the HBL forum. I want to thank again all the devs and testers involved in that project, in the past, the present, and the future :)

Download here, as usual, and enjoy your homebrews :)

Today I submitted some work in progress in our SVN. I don’t plan to release a binary for this version, because it is still work in progress. People are free to give it a try, but I recommend to not widely distribute this version of HBL.

Over the past months, we’ve taken the (bad) habit of making a huge release with each revision of the SVN. We entered a vicious circle to prevent other sites from “stealing our thunder”, and instead of “making a release with each revision”, the rule slowly became “wait until we’re ready for a release before submitting code”. This is not how SVN is supposed to work. This way of thinking has almost stopped our progress on HBL, and overall this was a bad thing. So we’re going to try very hard and change this, by using SVN “normally”: submit more often and release when we are confident.

I still expect that some people will compile and distribute versions of HBL R102, just to have the “latest and greatest”. Therefore I will try to be as clear as possible: a new revision in the SVN doesn’t necessarily mean an improvement. When we (the people actually developing the HBL, that is, currently, JJS and myself) are confident that a revision of HBL is worth releasing, you will hear it directly from us, either here or in the HBL forums, and we will do a release.

We DO accept bug reports for the latest SVN version, but only if the people who report bugs know what they are talking about.

HBL R102 is a work in progress to improve the internal stability of HBL, and to bring compatibility with Hot shots golf 2. We haven’t started using the data we gathered from the memdumps yet, so most likely, this version will NOT work for you if you have hotshots golf 2, just be patient. For hot shots golf1 or Patapon users, this revision changes absolutely NOTHING.

Of course people are free to compile and distribute R102, but if people ask you why the latest revision is not available on the official page, tell them it’s because the devs estimate that it’s not worth releasing. By the way, just so you know one of the major reasons behind this decision: before I do a release, I test HBL with all exploits on as many consoles as possible. This process usually takes several days. I don’t think anybody else who release binary versions of HBL does that.

Let me state this once again: from now on, a new revision in HBL’s svn will NOT necessarily mean a new release. When we feel ready for a new release, it will be announced here.

The recent announce of a Work-In-Progress HEN for OFW 6.20 isn’t stopping us from working on the HBL. I am actually hoping very strongly that anything we can do on HBL will help for further progress on Kernel access for firmwares 6.3x.

Quite some time ago, J416 released HBL R95 for minna no golf 2 (the Japanese version of Hotshots golf 2), and we already knew when we released HBL for Hotshots golf, that the sequel was vulnerable too. We took our time, mostly because I was busy with other stuff (understand: super lazy), but HBL for the hotshots golf 2 is coming, for all locales (JP, EU, US). The code is pretty much ready, but we need a bunch of memory dumps to make this thing work on as many firmwares as possible.

People who want to help us getting this thing out of the door can go to the HBL forums, where they will be able to get a memory dumper to help us (it’s one push of a button, I highly encourage you to help). The funny news is, Everybody’s golf 2 (the european version) was added to the PSN a week ago. Question is: was it patched? I haven’t tested it yet…

Err, I talk much…here’s a quick summary:

  • HBL 102 will have a few bug fixes, and will add compatibility with the hotshots golf 2 (US) , everybody’s golf 2 (EU) , and hopefully minna no golf 2 (JP) exploits
  • You can already download and try a hello world for Hotshots golf 2 (US) here. h.bin goes at the root of your memory stick, the Savegame in the “PSP/SAVEDATA” folder. Run the game, and click on “continue”.
  • People who want to help with the development of HBL for these exploits can go here. No programming skill is required but we can’t do it by ourselves.
  • We expect the hot shots golf 2 exploit to have more homebrew compatibility than the hot shots golf 1 exploit.

Until the release, enjoy this proof of concept video, Wagic running through HBL with the hotshots 2 exploit:

Almost a year ago I published a small chart giving a summary of the “hackability” of PSP based on the model and the firmware. Things have changed over a year, and with the recent announce of a 6.20 Kernel exploit (and associated HEN) by Total_Noob, they will probably change again very soon. But if you just bought a PSP, all the current possibilities are probably a jungle to you, and you are wondering what your options are. Here’s a quick chart with the current status:

Overall I think it looks way better than the chart a year ago, don’t you think? Below are details for each model.

PSP Phat and PSP2000 (except ta88v3)

If you own a PSP Phat (PSP-1000), or a PSP Slim (PSP 2000) that is NOT a Ta88v3, then your PSP, independently of its firmware, is 100% hackable with a pandora battery. It’s been the case for many months now, and it will not change as the exploit used for the pandora batteries is a hardware exploit and cannot be fixed with a new firmware.

PSP-3000 and TA88v3, Firmware 5.03 and below

If you are the unlucky owner of a “doomed” motherboard, but happen to have a firmware 5.03 or below, your PSP is “half-hackable” through the laughing man tiff exploit and the associated Homebrew Enabler, better known as “ChickHEN”. “half-hackable” means that your PSP can have all the features of fully hackable PSPs (homebrew, plugins, customizable themes, ISOs,…), but unlike fully hacked PSPs, if your hard-reboot your PSP, you’ll have to run the hack again. (For those who still don’t know, putting your PSP in sleep mode works fine and is the best thing to do to keep the HEN in Ram)

PSP-3000, PSP Go and TA88v3, Firmware 5.05 up to firmware 6.20

Half-Byte Loader allows you to run most homebrews on these models, through a vulnerability in the Patapon2 Demo. Additionally, Total_Noob announced yesterday that he was working on a HEN for these models. A HEN will basically bring you most features a Custom Firmware can have, but you’ll have to be patient (like the rest of us).

PSP-3000, PSP Go and TA88v3, Firmware 6.30/6.31

Half-Byte Loader allows you to run most homebrews on these models, through a vulnerability in the Hots Shots Golf game. Total_Noob’s HEN is not planned for these firmwares, but he mentioned that a downgrader to 6.20 might be doable. There’s still goog hope to get kernel access on these firmwares in the foreseeable future.

Vocabulary

Homebrew: User made (non official) applications. These include games such as Wagic, utilities, emulators…
ISO: In the PSP world, digital copy of a game, most of the time unencrypted, preventing it from running on an Official firmware. ISOs are often associated to game piracy.
plugin: Homebrews that are loaded in the Ram of the PSP to extend its functionalities. For example, the music plugin allows to play MP3s while playing a game or a homebrew on the PSP.
HEN: Homebrew ENabler. A program that patches the PSP Ram to allow running unsigned code (Homebrews). unlike eLoader, a HEN is in the Ram and therefore doesn’t require to be launched everytime you want to run unsigned code. To do this a HEN usually requires a Kernel exploit.
TA88v3 :A Model of Motherboard that was introduced on the PSP2000 in summer 2008. It fixes the vulnerability used by the pandora batteries. Several techniques exist to identify your PSP Motherboard. If you have a PSP 2000, the easiest way to identify if it has a “doomed” motherboard is to try a pandora kit (battery + memory stick) on it.

HBL Alternate menus  

Lots of people contact me and other HBL devs to get improvements in the HBL menu. I do take them into account, even if I haven’t released any new release of wMenu in a while, but did you know that you can actually choose your HBL menu among a series of existing ones? Or that you could actually create your own?

A while ago (when wMenu was introduced), I moved the menu away from the core of HBL, making it a homebrew. The initial goal was to get compatiblity with n00bz’ eMenu–, but I ended up creating wMenu instead. Since the menu in HBL is a homebrew, anybody can create one as long as they respect a few rules.

If you’re interested in creating your menu for HBL, it is quite easy. Your menu has to follow a few rules to communicate with HBL. A good example on how that works is the “default” menu for HBL, which source code is here:

http://code.google.com/p/valentine-hbl/source/browse/trunk/eLoader/menu/main.c

The code of this basic menu is open source, but as I stated a while ago on advancedpsp.tk, the necessary API to communicate with HBL is an exception. Basically, you should feel free to use the following code in your own menu, even if you decide to go close source:

?

typedef struct
{
	unsigned long        APIVersion;
	char       Credits[32];
	char       VersionName[32];
	char       *BackgroundFilename;
        char        * filename;   // The menu will write the selected filename there
}	tMenuApi;

and the part that reads  the contents of this structure in main.c. The value stored in settings->filename in HBL is the initial path that was chosen by the user for their homebrews (this is a configuration value in HBL’s config). Feel free to use it or ignore it, as you want.

    if (argc > 1) {
        char * hex = argv[1];
        *(hex + 8 ) = 0; //bug in HBL ?
        fprintf(stderr, "Location: 0x %s\n", hex);
        settingsAddr = xstrtoi(hex, 8);
    }
    fprintf(stderr, " settingsAddr : %d\n", settingsAddr);
    if (settingsAddr) {
        tMenuApi * settings = (tMenuApi *) settingsAddr;
        ebootPath = (void *) settings->filename;
    } else {
        ebootPath = dummy_filename;
    }

From then, the ONLY thing you need to do, is write the full path of the eboot you want to run into settings->filename, then exit your homebrew with a normal call to sceKernelExitGame. HBL will handle the rest.

There’s only one special rule, if instead of a full path to the homebrew, you write “quit” inside of settings->filename (then quit the menu with sceKernelExitGame), this will ask HBL to quit back to the XMB.

I said that alternate menus exist for HBL. The SVN source of HBL comes with a basic menu, and my own releases ship with wMenu, that you probably already know:

But there are other menus coded by other devs, which have different options, and that might fit your needs better.

SimpleMenu by Nymphaea is a nice text-mode menu with scrolling and some additional features

Download source

xenu by Mr.X can browse folders, and offers some neat configuration settings, and overall a nice clean interface.

Download source

Those are only examples, as long as you follow the basic API, anybody can create a Menu for HBL, and, really, the only limit to what the menu can do is your imagination. If you want your menu to play mp3 in the background, go for it! A menu for HBL is probably an easy and useful way to start coding homebrews, even if you just began coding on the PSP.

I know that other menus for HBL are floating on the internet (some of them were unfortunately lost when advancedpsp.tk closed, but remember that we now have a new forum for HBL related discussions!), if you created a menu for HBL, don’t hesitate to showcase it :)

I discussed with M0skit0 and JJS yesterday regarding the end of advancedpsp.tk. We’ve received many offers from lots of people regarding new solutions, but the fact is that we have trust issues :)

I don’t pretend to replace the great resource that was m0skit0′s website. I don’t even claim to have done the work done by TiPi and previous advancedpsp.tk moderators with h4ck.fi.st. But I think several resources regarding PSP Hacking, and especially, HBL, can exist at the same time :)

We discussed all the possibilities with m0skit0 and JJS, and opening a new forum on my own server is the solution that we chose for now. I will now use that forum to discuss HBL compatibility and development.

We could also have asked lan.st, or ps2dev, or other well known forums, but we want this forum to be a “noob friendly” place. A place were people can discuss crashes, request features for HBL, etc…

I could also have added subforums to the existing Wagic forums, but we decided that we don’t want to merge two different communities.

Hence a new forum, currently empty. I’m the first one to complain about people who advertise about an empty website, so I’ll say it once again: I don’t pretend to offer anything better than other forums for now, but we’ll get there as the community grows.

The scene survived the death of dark-alex.org, it will survive the death of advancedpsp.tk. I’m crossing fingers for the future of wololo.net/talk :)

The party starts here

advancedpsp is gone  

Update: m0skit0 got a (bad) reply from his hosting service:

I got final reply from 000webhost, and it’s definitely not recoverable. The forum is lost forever. I have no previsions on setting up a new site.

Please spread this on as many sites as possible so people would be aware about that hosting site erases accounts without previous warning.

The forums at advancedpsp.tk were very strictly moderated, and as one of the mods I am 100% sure nothing illegal happened there. So, there you go. If you are a site owner, we don’t recommend you to use 000webhost.com, as it seems they will erase your account for no reason.

Original post:

Many of you have noticed that m0skit0′s site advancedpsp.tk, which hosts the main development forum for HBL, is currently inaccessible. M0skit0 is aware of the situation and is currently dealing with the company providing the hosting in order to solve the issue.

This new revision fixes many stability issues on the golf exploit (all versions), and improves compatibility on the Go, thanks to JJS’s “perfect syscall” patch for this model. Owners of the PSP 2000/3000 have once again less luck, but they will still benefit from this update which improves the loading stability of HBL. Although this revision shouldn’t change anything for Patapon2 owners, it is the recommended revision for everyone.

I want to thank the people who donated over the past weeks. The money was used mostly to buy UMD versions of the hot shots golf, to help with debugging on firmware 6.31. This greatly helped with fixing some bugs with HBL on the latest firmwares.

Download here and enjoy your homebrews :)

Yesterday I mentioned reports from people who are having difficulties running HBL on the hot shots golf UMD (US). Although I don’t have the exact same testing conditions as these people, I was able to get a UMD of the US Game to test.

I was able to run the hello world, as well as HBL R100 on a PSP 1000 in 6.31, and on a PSP 3000 in 5.03 with the “greatest hits” version of the UMD, without any problem. Based on this test, I believe the exploit works correctly independently of the firmware/psp model on the hot shots UMD I have. After discussing with a few users, it turns out there are several versions of the hot shots golf UMD, and it could be that one of these versions is not (yet) compatible with the exploit.

If you own the hot shots UMD, please let me know the following things:

  • Please describe the UMD you own. Is it the “greatest hits” version  (yes/no) ? If not, does the UMD have a “update firmware” feature (yes/no), and if so, what firmware does it ship with?
  • Does the hello world work for you (yes/no)?

Since getting anything else than the “greatest hits” version is difficult for me, and assuming this really is the reason this is not working for some people, I might unfortunately not be able to help people much more on this issue. Hopefully other hackers will have access to a “non working” UMD, and can maybe see what’s wrong. (that, or some kind soul will send it to me for investigation :) )

On the bright side, the “greatest hits” version seems way easier to find than the older versions!

Several people have reported issues with HBL running through the UMD of hot shots golf on some PSPs (most reports were for PSP 3000). The symptom: even the hello world doesn’t run.

I would usually assume that the error comes from the user (and, that’s initially what I did), but some users have been as far as buying the PSN version of the game in order to compare, and discovered that the exploit was working perfectly on the PSN version, but not on the UMD.

This might be a few isolated cases, but this is to let you know that I am aware of the situation and I will start investigating. Also, if you have a PSP 3000 6.30/6.31 with the UMD of hto shots golf, I am interested to get your feedback. Does the hello world work for you?

Important note: this guide is now somewhat obsolete, and in particular if you plan to port VHBL, I recommend to read the new version of the guide instead. This page is kept for archive purpose.

That’s it. You found a user mode exploit in a game, you were able to write a binary loader, so now what 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 unhackable PSPs, 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.31. 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, the quality of syscall estimations (and therefore, 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.

The sources of HBL can be downloaded here (SVN client required)

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=hotshots will compile HBL for the hot shots golf (US) exploit. At the time of this writing, 4 such folders exist: minna, patapon2, hotshots, everybody.

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 patapon2 folder:

The folder contains 6 files and 2 folders, that you will want to adapt to your exploit. I will describe each of them separately (almost)

3. Create your exploit’s files

tools

You don’t really need that folder, but you might want to create tools for your exploit, such as a memory dumper. you can put these tools in this folder.

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, and sdk_hbl.S

create an empty config folder, it is needed afterwards. The contents of this folder, as well as sdk_hbl.S, are automatically generated by a ruby script that you can find in eLoader/tools/imports.config generator/eLoaderconf.rb. Just edit this script with your favorite text editor to see what’s going on there.

We basically have a hash for each exploit, which tells HBL where to find interesting stubs. The theory on how to find these stubs can be found on our /talk forums, but we also happen to have a ruby script that does it for you. That ruby script is eLoader/tools/stubs.rb. You need to have a usermem dump (that you can get either from psplink on a hacked psp, or by running a usermem dumper with your newly found exploit) and name it memdump.bin before you run the file stubs.rb. You need to get one user mem dump per firmware you want to support, so you might need help from other hackers or beta testers to get those.

To know which libraries to get stubs from, you can run “modlist” in psplink. The most important one is the one from your game. it is usually called “main”, but the name can vary. For patapon2, it was called “Labo”.

So, basically, run “stubs.rb” on your memory dump, and this will give you the addresses you need for your firmware. Do that again for as many firmwares as needed, and copy/paste the results accordingly in eLoaderconf.rb

exploit_config.h

This is the meat of the changes, the part that requires the most work. This include file defines a bunch of exploit-specific variables that will be integrated into HBL when you compile it.

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 this value by creating a small h.bin that will just try to alloc 200kB without specifying any address, then retrieve the address created this way:

u32 uid = sceKernelAllocPartitionMemory(2, “test”, PSP_SMEM_Low, size, NULL);

u32 addr = sceKernelGetBlockHeadAddr(uid);

//then log addr in a debug file or something, this is what you’ll use for HBL_LOAD_ADDRESS

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 0×00!), 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.

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 eLoaderconf.rb to generate the sdk and the config files. This will generate config files for ALL exploits defined in eLoaderconf.rb, including yours. (Be sure to have created a “config” subfolder in your exploit’s specific folder)
  • run make FOLDER=yourfolder
  • 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.

I’ve received lots of requests over the past days regarding Half-Byte Loader. Either on this blog, by PM in various forums, on youtube, or directly by email. I can’t answer all these questions because I don’t have the time to do so, but I do read all of them and I’m taking them into account. Let me try here to answer most of the questions:

  1. HBL does not load isos, and we have no plan to work on such a feature. This is not for “ideological” or “ethical” reasons, but because it is technically very difficult (if not impossible), and absolutely not our goal. Other teams are of course free to work on such a project, although so far all public attempts at an iso loader in user mode have failed.
  2. HBL on the golf exploit is still quite unstable, and lots of people are complaining about loading failures, etc… Complaining on my blog will NOT help you getting your problem fixed. If HBL does not run correctly for you, what you need to do is to install the DEV version that matches your version of the game (EU,US,JP), and then submit your DBGLOG file on advancedpsp’s forums, in the dedicated thread . We don’t accept bug reports without a DBGLOG file, not because we don’t like to be mean, but because we can’t help you without this file.
  3. If you’re not getting a DBGLOG file at all, or if it is empty, you are doing something wrong! Be sure that you are using the version of HBL that matches your game (for example, HBL for the US version of hotshots golf will NOT work on everybody’s golf EU). Also double check that you are copying the files in the correct place on your PSP. If everything else fails, start a thread at advancedpsp.
  4. We are actively working on fixing the issues, and we have a bug list that we are working on: you can track our progress here.
  5. More than ever, we need help. By porting HBL to 3 new exploits, we literally multiplied by 4 the amount of work needed, especially for testing. We need developers to help with this project, this is why it is open source. If you want HBL to become better, actively help! We also lack PSPs with firmware 6.31, and UMDs of all the versions of the game to do effective testing, so if you have money and want to help, donations (money, hardware, umds of the game) are more than welcome. Contact me directly by email at wagic.the.homebrew@gmail.com, or check here for donations. Remember that you donate to thank us for the work done so far, and not in expectation of future work.
  6. It seems the vulnerability exists in the sequel of the hotshots game. Please feel free to write “hello world” proof of concept exploits for hotshots golf 2 or everybody’s golf. Porting them to HBL should then be a matter of days.
  7. If HBL does not load your favorite homebrew, we accept bug reports on a case per case basis. Basically, if the homebrew is majorly used, OR if the homebrew works on the patapon exploit but not on the golf exploit, OR if the homebrew worked in a previous version of HBL but doesn’t work anymore, then it is a good candidate for bug report. We don’t accept bug reports for homebrews that require kernel mode. If you don’t know if the homebrew requires kernel mode, ask to the homebrew creator.
  8. The best way for you to get a homebrew to work on HBL, is to contact the author of the homebrew, and talk to them about HBL. HBL now runs major homebrews quite smoothly, and most of the time, “good coding practices” should be enough for a homebrew to run on HBL.

« Older entries § Newer entries »