uofw / uofw Goto Github PK

The unofficial Official FirmWare, a complete latest PSP firmware reverse engineering project

License: Other

C 95.13% Assembly 4.12% C++ 0.30% Shell 0.12% Makefile 0.34%

uofw's Introduction

uOFW

This project aims to reverse engineer the basic PSP kernel & hardware to create an up-to-date technical documentation of the system as well as to provide a free and open source vanilla firmware.

To learn more about uOFW (including examples where it has been used by the PSP community), please check out this presentation.

The current progress on the project can be found on the Current Modules Status wiki page.

Documentation

PSP Kernel API Documentation
PSP Hardware and Software information can be found at uofw/upspd.

Installation

You can run components of uOFW by following the directions at uofw/uofwinst.

Contributing

This project is far from complete. We welcome everyone to help us.

To get started, please read the wiki. It contains the necessary information to contribute to uOFW.

License

This project is licensed under the MIT license. It includes code from the PSPSDK which is licensed under the BSD license. For more copyright and license information, see COPYING.

Questions or need help?

You can chat with us the following ways:

via the PSP Homebrew Community Discord server (preferred)
via e-mail: [email protected]

uofw's People

Contributors

Stargazers

Watchers

uofw's Issues

Fix iofilemgr

Damn, I've already spent some time trying to fix it.

Controller module: Fix possible typo in the _sceCtrlReadBuf API or add a comment

I have noticed this code years ago yet somehow never went through with supplying the simple fix:

uofw/src/ctrl/ctrl.c

Line 2103 in d5bf388

pData->rsrv[2] = ctrlBuf->rsrv[3];

I don't currently have the disassembled controller module to look at but I'm pretty sure that the code is supposed to be

pData->rsrv[3] = ctrlBuf->rsrv[3];

If, however, that is a mistake on Sony's part, then we can either correct it or leave it as is and provide a comment instead. I think we opted not to fix Sony's errors since for now we are just reverse-engineering the firmware and thus creating a basis for other work (such as writing exploits which make use of Sony's coding oversights).

Reverse Engineer modulemgr

Module Manager: Complete API documentation

Fix loadcore

Issues might be due to the installer as it's not showing anything at all, as far as I remember.

Module Manager: Fix crash

The module currently causes a crash during the PSP boot process.

Reverse Engineer isofs

Hybrid approach (mix of HLE and LLE) for a PSP emulator

I may resume my work on my psp emulator, but with a "small" change in my plans: going into an hybrid approach between HLE and LLE for modules including kernel ones. My plan is to let the recompiler to handle most of kernel codes instead of using a native code by keeping in a HLE state only the NID functions dealing with direct accesses to MMIO regsiters for instance.

So I post here because I may need some help to understand how the firmware is booting and installing its modules so I can have a rough idea which modules (or libraries per module) I can really keep in a LLE state.

Thanks

Reverse Engineer idstorage

Handle Different PSP Versions (_0g.prx) of a Module

We need to do something about the build system, maybe macros etc. so it is easily handled.
It shouldn't be hard, most of the work being RE'ing (and checking identical functions, etc.) the other module versions.
The modules with different versions are: codec, display, hpremote, impose, loadexec, memlmd, mesg_led, pops, power, wlanfirm, eflash (GO only), input (GO only).

Modules should be considered finished and ready to release only when all the versions are RE'ed.

kd/ modules present in all firmwares but the GO one:

ata.prx
fatms.prx
umd9660.prx
umdcache.prx
umdman.prx

kd/ modules only present in the GO firmware:

bsman.prx
btdun.prx
eflash_05g.prx
fatmsef.prx
hidsvc.prx
input_05g.prx
msemu.prx
padsvc.prx
usbbsmcdc.prx
usb_host.prx
usbps3controller.prx
usbstoreflash.prx

Reverse Engineer display

prxtool Tutorial Needs to Be Fixed

Hey guys, I am new to the reverse engineering but was told by noname120 to open an issue when I got this problem. The problem is that the link to the precompiled version of prxtool is broken, it takes you to the homepage. I think it is really easy to upload a link to the compiled version of prxtool. Also the instructions given to run the prxtool do not work as said in the tutorial, actually it didn't work at all with me. According to @devnoname120 a NID table is needed otherwise the functions are not resolved.

Reverse Engineer rtc

Inefficient Builder

The builder, @uofwdox, is a waste of a account. Here are some improvements that can be made:

switch to (C ontinuous I ntegration) platform like travis-ci
enable travis builds
add deployment to gh-pages b5aa896

Controller API update

A bunch of APIs of the Controller module should be updated to their presumed correct namings (based on PS Vita SDK documentation). These APIs include the following which for now have custom names:

Current Name	Proposed Name
SceCtrlDataExt	SceCtrlData2
sceCtrlPeekBufferPositiveExtra	sceCtrlPeekBufferPositive2
sceCtrlPeekBufferNegativeExtra	sceCtrlPeekBufferNegative2
sceCtrlReadBufferPositiveExtra	sceCtrlReadBufferPositiv2
sceCtrlReadBufferNegativeExtra	sceCtrlReadBufferNegative2

These APIs are used to obtain input data provided by a wireless controller (such as the DS3).

Edit: Validated the proposed names by checking their SHA1 hashes.

Fix sysmem

It's not booting. I'll probably do it later, but if other people want to, feel free to help.

Reverse Engineer lfatfs

Not an issue but a presentation of snowman decompiler for Allegrex

Hi,

I'm working to integrate Allegrex support in snowman decompiler. While working on it, I will be glad if some other people here may contribute in snowman, especially in the field of binary parser like PRX module. Or even trying to test it with ELF file to check what kind of issues or improvements snowman for Allegrex may need.

The place is here and the topic where it starts is here.

Regards.

Correctly Capitalize Issue Titles

The issue and pull request title is considered as a title. Please use proper capitalization rules. For code simply preserve capitalization. Examples:

Reverse Engineer loadcore
Please Update the Links

Reference:

Travis: Documentation update (gh-pages) is currently broken

I just did a couple of commits to the master branch and noticed that our gh-pages branch for our API documentation is no longer automatically being updated. See the following (truncated) travis build output:

Cloning into '.'...
[...]
Generating code for file /home/travis/build/uofw/uofw/include/audio.h...
[...]
[gh-pages 0524498] Rebuilt docs for 2b16aaaae283d5f11f2ecc83771e34abc91e7a2f
[...]
rewrite utility__screenshot_8h_source.html (73%)
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/uofw/uofw.git/'

For a full output, you can check a full travis log.

Looking at the script it seems the error happens starting with (so when the generated doc files need to be committed to the gh-pages branch):

uofw/.travis.yml

Line 54 in 2b16aaa

git config user.email "[email protected]"

I wasn't involved in the original setup so I'm not too well-versed in what's currently broken here and why it broke. I could look into this but won't be able to make any promises. Perhaps one of you guys (@artart78, @joel16, @devnoname120, @0xcaff) can help out here?

LAN.st alternatives

Hello!

I was going through the README.md and seems like LAN.st has been down for a while. Any alternatives for it as the guides it had were quite helpful in understand PSP knowledge.

Fix exceptionman

Controller module: Is the SceCtrlData API correct?

In commit f099b78, the SceCtrlData API got updated:

Looking at the official PSP 6.60 SDK documentation, however, the SceCtrlData struct is still defined as this:

typedef struct {
    u32 timeStamp;
    u32 buttons;
    u8 aX;
    u8 aY;
    u8 rsrv[6];
} SceCtrlData;

@kokibits I think I recall you worked on some PSP plugins dealing with controller input so you might have some insight here which I don't have. Would you mind commenting on why you made the change in the above mentioned commit for the SceCtrlData struct?

FWIW, the PS Vita SceCtrlData's struct also does not contain any info about external controller input. That data is exposed solely via the SceCtrlData2 struct.

Reverse Engineer umdman

Reverse Engineer ata

Rewrite Documentation

The documentation is great but it is written by non-native english speakers. It is too verbose in some places and hints of gender based grammar.

Make sysmem (& loadcore?) boot with the installer

Current, our sysmem.prx does not boot at all with the uOFW installer.
However, the decrypted original sysmem.prx (given by psardumper) does (probably thanks to the patches I added to the uOFW installer a while ago).
So, this is probably due to the executable format:
We use:

sections (unused)
2 segments:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00000000 0x80011d10 0x139f8 0x14018 R E 0x10
  LOPROC+a0      0x013dc0 0x00000000 0x00000000 0x064a0 0x00000     0x10

LOAD: offset: offset for actual sections content in the ELF (PRX) file
physaddress: 0x80000000 + offset to .rodata.sceModuleInfo
filesize: size of data in file (-> end of .data stored in file)
memsize: filesize + size of .data initialized to zero

LOPROC+a0: added in kprxgen (compared to the original prxgen) to make standard kernel modules work, probably
offset: offset to the beginning of section relocations in the file
filesize: size of relocations.

relocations are standard ELF relocations: R_MIPS_26 (for jumps), R_MIPS_HI16/R_MIPS_LO16 (for lui..lw/sw and so on), R_MIPS_32 (for data)

Original (decrypted) sysmem.prx uses:

no sections
3 segments:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000c0 0x00000000 0x8001200c 0x13b0c 0x13b0c R E 0x40
  LOAD           0x013c00 0x00013b40 0x00000000 0x00094 0x00ac4 RW  0x40
  LOPROC+a1      0x013ca0 0x00000000 0x00000000 0x01af4 0x00000     0x10

LOAD: same as the first LOAD segment in what we use, but filesize = memsize
LOAD (2): offset of .data probably, virtaddr = (offset - offset of first LOAD)
filesiz = size of data in file, memsiz = size of data (the rest being set to zero)
LOPROC+a1: offset & memsize: size of relocations ("type B" in PRXTool).

relocations are Sony's segment relocations (I don't think they exist anywhere else). They're correctly handled by PRXTool, a writer (and doc) could be made from this.

From here, we have two solutions:

patching kprxgen so it does the same as the original sysmem module
making reboot.bin work with our current kind of module.

According to fa8ad93, it should work as-is, but it doesn't. I'll investigate.

Fix ge

Wiki: Referenced MIPS ASM materials constantly broken over the years

Due to constant ownership changes over the MIPS product family over the years, the referenced MIPS ASM documentation in our wiki is frequently broken. More precisely, the documentation we link to with the MIPS32 Architecture (official documentation) bullet point.

Proposal: Upload the necessary documentation to our uPSPD repo and link to it from the wiki. We already have a bunch of material uploaded in its gh-pages branch thus I would just upload the additional MIPS documents into the same directory.

Document workflow

Looking at this commit 03e613b, I think we should have some consensus on how our workflow should work.

Since there is some degree of collaboration on modules, we're likely not going to be able to get the nice, linear rebase workflow, so I propose the following:

No code directly commited to master
All modules reversed in topic branches
Reviewed pull requests into master
A 👍 just to show that someone else has looked at it would be nice for all code submissions (documentation is a little more relaxed, although the PR as a record seems like a good idea to me)
Merge/cherry pick FROM master only if absolutely necessary
Merge/cherry pick TO master once per branch (when the feature is complete)
Of course, there may need to be bug fixes after this, but I think that should be done in a new branch.
No cross-branch merging/cherrypicking
No rebasing branches that have already been pushed
Delete merged branches
You can always create a new branch with the same name later

These rules are meant to try to keep some degree of quality control on our code and limit the number of merges and duplicate commits that make the history difficult to read.

This might be a bit naive, but I think we can work that out as a group. Let me know your thoughts, please.

Debug code cannot write files to ef0

Only ms0: (memory stick) is mounted.

Restructuration of errors.h File?

Right now, https://github.com/uofw/uofw/blob/master/include/common/errors.h lists general (kernel) errors as well as dedicated module specific errors (starting with SCE_ERROR_UTILITY_INVALID_STATUS). I'm currently thinking about separating these two error code classes for the sake of clarity. Each module would get its own module_error.h file with the dedicated errors inside. That way, only the commonly used error codes would remain in the common directory and specific error codes get their own header file.
What do you think about this?

Loadcore: Shift error in sceKernelApplyPspRelSection

in loadelf.c, sceKernelApplyPspRelSection, at line 919, this code,
addrSegIndex = ELF32_R_ADDR_BASE(relocInfo[i].r_info >> 16); //0x000052C8

ELF32_R_ADDR_BASE is a define that right shifts the input 16 bits, and as you can see, it's being right shifted twice with 16 bits, so addrSegIndex will always equal 0.

Originally posted by @qwikrazor87 in #21 (comment)

Define Milestones/Releases

To prevent people from thinking "uOFW is not organized", "they want to RE all the modules, which is unrealistic", I thought about defining milestones for uOFW. I based my organization on the boot order (the earlier it is booted, the most important is a module) and the fact that it accesses hardware or not (through the 0xBC...... addresses).

Here is my idea (() = RE'ed and working, [] = RE'ed, <> = started)

Milestone 1: everything up to init.prx: [sysmem], [loadcore], [exceptionman], [interruptman], threadman, , (systimer), [iofilemgr], memlmd, & (init). As you see, this goal is quite close and really realistic. It includes all the most important modules of the firmware.
Milestone 2: most important drivers (and modules between them in the boot order): (loadexec), , [ge], , (syscon), rtc, lfatfs, (clockgen), (mediaman), ata, umdman, umd9660, isofs, display, (ctrl), (led), power.
Milestone 3: less important drivers: msstor, codepage, fatms, (codec), [audio], hpremote, , usb, wlan, (wlanfirm), registry, mgr, msaudio, chkreg, mesg_led.

That would leave another milestone before VSH, but it's so far away from the current state that it's useless to define it for now.
Maybe some important modules, like mesg_led which handles decryption, could be RE'ed before. Modules including drivers which are not in the list are: irda, sircs (both not in pspbtcnf), (me_wrapper), npdrm, popsman (the list may not be complete). Maybe these could be moved to the milestones (me_wrapper is already RE'ed but very ugly for now).

It would be nice to make a release each time a milestone is completed, with all of its modules tested and working of course.

What do you think?

SysMemForKernel_7FF2F35A

uofw/src/sysmem/exports.exp

Line 59 in e018ffe

PSP_EXPORT_FUNC_NID(SysMemUserForUser_945E45DA, 0x7FF2F35A)

Line 59
PSP_EXPORT_FUNC_NID(SysMemUserForUser_945E45DA, 0x7FF2F35A)
Is this correct? Function NIDs are always the same as their (unknown) function names (From what I've seen at least)
The NIDs 0x7FF2F35A refers to SysMemForKernel_7FF2F35A from what I know, but here its referring to SysMemUserForUser_945E45DA. Shouldn't SysMemUserForUser_945E45DA have 0x945E45DA as its NID?

Fix interruptman

Update to 6.61

A new PSP firmware version has been released!

I've checked the differences between 6.60 in detail. Here they are:

added 05g (PSP Go) stuff [encrypted, cannot compare to 6.60]
no more reboot_{07,09,11}g.bin?
new certificates
new version number in many modules (in module info)
changes in cert_loader.prx [inside code]
changes in pspbtcnf*.bin [version number]
changes in lflash_fatfmt.prx [inside code]
changes in libhttp.prx [inside code]
changes in libssl.prx [MANY changes inside code]
changes in loadexec_*.prx [probably only reboot.bin + addresses because size changed]
changes in *_files_table.bin (psardump files)
changes in nandipl_*g.ipl [probably mostly related to other modules changing]
changes in reboot*.bin [probably mostly related to other modules changing]
changes in vsh/etc/index_*.dat
changes in vsh/etc/version.txt
changed version number in init.prx [in devkit version printing]
changed version number in loadcore.prx [CheckDevkitVersion()]
changed version number in power_*g.prx [number in sub_00001AE8(), in structure passed to scePower_driver_C463E7F2()]
changed version number in sysmem.prx [sceKernelDevkitVersion() return value], lfatfs.prx [sceLFatFs_driver_F28896C0() return value]
changed version number in htmlviewer_plugin.prx [twice]
changed version number in htmlviewer_utility.prx [looking like one of the numbers in htmlviewer_plugin.prx]

That'd need no change in uOFW (just updating SDK_VERSION to 0x06060101, since the really modified modules haven't been RE'ed yet), but I wanted to share it with you. :) It's quite disappointing that the project is quite dead now, but I guess everybody's been too busy, and RE'ing is a long and hard task.

Reverse engineering work for the PS Vita

Hey,

This is not directly related to uOFW but I wanted to let you guys know about the status of the PS Vita. Team molecule has created a hack named HENkaku that allows to run native User code, and taiHEN that allows to run code with Kernel privilege on the PS Vita.

Among other things, we can dump Vita modules; this is where it gets interesting for us.

vitadump allows to dump user modules to the ELF format.
vita-analyze allows to fix them and add symbols so that imports use real function names from a NID database.
IDA and radare2 allow to open these ELF files and reverse engineer them.

There is a need for more reverse engineers figuring out functions and their arguments for the vitasdk, so if you miss reverse engineering stuff, join us!

Reverse Engineer lowio

Reverse engineer threadman

Collaborative work expected.

Reverse Engineer dmacman

Nearly finished apparently. 😄

Make modules patched by the uOFW installer (ProCFW) run as if they were patched

This issue is made of two parts:

first, it should be handled in the build system that some "security" checks should be disabled to act as if the module was patched by SystemControl
then, way should be found to patch modules on-the-fly, and most importantly, get specific addresses in it, and that would mean getting the patch addresses; the easiest way probably would be adding options in the uOFW installer, in the list.txt, to hold the needed addresses.

Reverse Engineer memlmd

Reverse Engineer power

Not really an 'issue' but something to keep things professional

There is a slight grammar mistake:
'Great! But what know?'
Should be:
'Great! But what now?'

It's located right under "Reading the PRXTool output" in the "setting up and using PRX tool" wiki. https://github.com/uofw/uofw/wiki/PRXTool

Fix systimer

Recent changes broke the module. Investigate, fix. Boom, done.

Controller module: Fix possible typo in the _sceCtrlReadBuf API or provide an additional comment

I have noticed this code years ago yet somehow never went through with supplying the simple fix:

uofw/src/ctrl/ctrl.c

Line 2103 in d5bf388

pData->rsrv[2] = ctrlBuf->rsrv[3];

I don't currently have the disassembled controller module to look at but I'm pretty sure that the code is supposed to be

pData->rsrv[3] = ctrlBuf->rsrv[3];

Edit: Verified that this is indeed a typo by looking at the MIPS ASM for the controller module.

Cleanup

Is this exe supposed to be committed?

Reverse Engineer umd9660

Controller module: Should not use custom API name

The sceCtrlExtendInternalCtrlBuffers API is using a custom name which is very likely not the official Sony name. However, uofw using this name here risks implying that this is the official name for this API. As such, we should stop using this name and rename this API to sceCtrl_driver_E467BEC8.