Editing 1.00 Bogus Firmware

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
= Description =
= Description =
This is an official testbench firmware update that was added to the Network Update servers in early January 2005. Sony did this to perform QA tests of the network update feature before the official 1.50 update launch.
This is an official firmware update that was released on the Network Update servers in early January 2005. Sony did this to make sure that a full system software update can be received and installed on the PSP hardware before the US launch.


As people started looking into the update server URLs and searched for possible updates. People started guessing possible URLs that may be hosting updates (only a dummy update file was hosted on regular servers at the time), one of those update URLs had an update list that pointed to a test update in PBP format that was eventually dubbed as the "1.00 Bogus Firmware". Source: [[http://lukasz.dk/mirror/forums.ps2dev.org/viewtopic9aad.html Network Update Tricks]]
Due to the design of the network update feature, they did not use update test servers and used the production servers. This allowed people to go into the 'Network Update', download and install the software causing a soft-brick.


Installing this firmware update, as-is, would cause a brick, Sony Public Relations at the time indicated that servicing these devices would not be covered by the warranty.
At the time, this was considered a brick due to the symptoms causing the hardware to no longer boot. There were several theories to why it happened such as the bootloader (IPL) being deleted due to missing a IPL driver in the updater. What actually happened was that the '''registry/user settings''' were not downgraded from the [[Release 1.00 (1.0.3)]] and the older system software (1.0.0) was not able to read it.  
 
There were several theories as to why the bricking happened were made, such as the bootloader (IPL) being deleted due to missing a IPL driver in the updater. What actually happened was that the '''registry/user settings''' were not downgraded from the [[Release 1.00 (1.0.3)]] and the older system software (1.0.0) was not able to read it. In 1.0.2+ the system will give the "blue screen of death" when the registry is corrupted and automatically fix itself.


In order to properly install it, you will need to install the system software, and then clear out the registry after booting. You can also utilize the registry patcher application to patch the 1.0.3 registry to have it downgrade to the older settings version.
In order to properly install it, you will need to install the system software, and then clear out the registry after booting. You can also utilize the registry patcher application to patch the 1.0.3 registry to have it downgrade to the older settings version.


While it can be installed over 1.0.3, the system will need a hard reset each time it is suspended. This is due to the power method being changed in 1.0.3 and thus its' IPL will break sleeping on older firmwares. This can be fixed by either replacing '''power.prx''' from 1.0.3 or using the correct IPL. The 1.0.0 IPL (kbooti.bin) leaked on the game '''NBA Street Showdown'''. The 0.9.0 IPL also works and can be found on a few UMD games: two of these are Ridge Racers and Shutokou Battle, located in the PRX folder as '''kbooti.bin'''.
It can be installed with the 1.0.3 IPL, however sleep mode does not work. According to the SDK changes log, this was fixed in later firmware revisions of 1.0.3 (1.00).
 
To make it run on retail units, you will need to remove the [[iplloader]] (first 0x1000 bytes) and make the following change to main.bin:
 
0x04000714 -> '''0x3224007F''' (masks some check used in the Baryon leaf like in newer IPLs)
 
Optional, for compatibility with TA-082/86 motherboards:
 
0x04000730 -> '''0x1000FF47''' (clockgen fix)
 
You can then use ipltool to reencrypt the IPL. Alternatively (not recommended) you can also patch IdStorage by changing byte 0x18 in leaf 4 (Baryon) from 0x94 -> 0x14. This will allow the IPL to boot without modifying it.


= Version Differences from Release 1.0.3 =
= Version Differences from Release 1.0.3 =
Line 29: Line 17:
It does not contain a DECI2P debugging module so its not certain how these messages would be seen, possibly through another active host file system receiving the TTY information.
It does not contain a DECI2P debugging module so its not certain how these messages would be seen, possibly through another active host file system receiving the TTY information.


The firmware uses loadcorei by default to allow plain modules to be loaded during runtime, and 'dlgsample_plugin' was a development sample for the dialog utility. Unlike the regular reboot, rebooti allows the loading of a decrypted loadcore/sysmem and pspbtcnf files. Both loadcorei/rebooti still enforce encryption checks for user/vsh PRX, but enable unsigned kernel PRX. All ELF may run unsigned just like in 1.0.3.
The firmware uses loadcorei by default to allow plain modules to be loaded during runtime, and 'dlgsample_plugin' was a development sample for the dialog utility. It's uncertain what rebooti.prx did differently than the rebooti.prx.
 
The reset combo (Start+Select+Square+Triangle) does not work on 1.0.0, this was implemented later on with 1.0.3.


= System Version Information =
= System Version Information =
Line 61: Line 47:


* GAME Category
* GAME Category
# UMD/Memory Stick Firmware Updates do not work, this is probably due to the startup information from the firmware's updates that contain more information than what the VSH is trying to read.
# UMD/MemoryStick Firmware Updates do not work, this is probably due to the startup information from the firmwares updates that contain more information than what the VSH is trying to read.
# All EBOOTs show up corrupt, as with the issue from above, this can only be mediated by using the bogus firmware PARAM.SFO since it matches the information that the XMB needs or patch the firmware's game_plugin to allow it to read the new information.
# All EBOOTs show up corrupt, as with the issue from above, this can only be mediated by using the bogus firmware PARAM.SFO since it matches the information that the XMB needs or patch the firmware's game_plugin to allow it to read the new information.
# Loading any game/application from the Memory Stick will cause a lower default memory allocation and current working directory error when the system reboots.
# Loading any game/application from the Memory Stick will cause a lower default memory allocation and current working directory error when the system reboots.


* VIDEO Category
* VIDEO Category
# While playing an hour long MPEG4 video from the Memory Stick, the video starts to desync the audio/video. The video starts slowing down but the audio continues to play in a normal speed.
# While playing an hour long MPEG4 video from the MemoryStick, the video starts to desync the audio/video. The video starts slowing down but the audio continues to play in a normal speed.
# Playing an MPEG4 video, and jumping an hour using the control panel options causes the same symptoms as above. This likely might be due to how the firmware buffers videos rather than seeking from UMD.
# Playing an MPEG4 video, and jumping an hour using the control panel options causes the same symptoms as above. This likely might be due to how the firmware buffers videos rather than seeking from UMD.
# (Not really a bug but an interesting development tidbit they left in), You can have multiple video folders under MP_ROOT. Where normally you'd have a 100MNV01 folder, and put in all your MP4 videos, with the bogus firmware, you can have multiple videos named such as 100MNV02, 100MNV03, etc. This would allow you to be able to categorize the videos in some way. They all show up normally under the VIDEO category regardless.


* MUSIC Category
* MUSIC Category
# Minor codec changes were made that cause specific MP3's from showing under [MUSIC].
# Minor codec changes were made that cause specific MP3s from showing under [MUSIC].


* PHOTO Category
* PHOTO Category
# If you delete the Digital Cameras folder it will cause the system to lock up immediately after exiting the category.
# If you delete the Digital Cameras folder it will cause the system to lock up immediately after exiting the category.
# Loading a large photo causes the viewer to act up, such as zooming into a photo will causing a 200% increase in size.
# Loading a large photo causing the viewer to act up, such as zooming into a photo will causing a 200% increase in size.


* SETTINGS Category
* SETTINGS Category
Line 102: Line 89:


# When loading a game/application from the Memory Stick will be allocated a very default low memory pool, this is fixed by patching the 'sceSystemMemoryManager' with one from 1.0.3 or specifying a heap size in the development of the application/game.
# When loading a game/application from the Memory Stick will be allocated a very default low memory pool, this is fixed by patching the 'sceSystemMemoryManager' with one from 1.0.3 or specifying a heap size in the development of the application/game.
# When loading a game/application from the Memory Stick, the current working directory (CWD) will not be set on boot causing application using the main argv variables to fail. This can be fixed by loading the application again via sceKernelLoadExec. The issue likely lies with the VSH equivalent of sceKernelLoadExec (vshKernelLoadExec).
# When loading a game/application from the Memory Stick, the current working directory (CWD) will not be set on boot causing application using the boot parameters to fail. This can be fixed by loading the application again via sceKernelLoadExec. The issue likely lies with the VSH equivalent of sceKernelLoadExec.
# When loading a UMD game, no audio will be outputted, this is due to the Media Engine API not being fully developed and causing the ATRAC3 audio to fail. This can be *only* fixed by patching in the 'me_wrapper' from 1.03 into the firmware.
# When loading a UMD game, no audio will be outputted, this is due to the Media Engine API not being fully developed and causing the ATRAC3 audio to fail. This can be *only* fixed by patching in the 'me_wrapper' from 1.03 into the firmware.
# Network Setting Configurations are not indexed properly, where the first network connection is indexed as '-1' not '0'.
# Network Setting Configurations are not indexed properly, where the first network connection is indexed as '-1' not '0'.
= Oddities / Unfinished Functionality =
# If a UMD (or DVD) does not have a PARAM.SFO in the root "disc0:/PSP_GAME/" directory, it will try to load a PARAM.SFO from "disc0:/PSP_GAME/SYSTEM/PARAM.SFO". (Note the SYSTEM directory VS the usual SYSDIR directory.)
# ATRAC3 is available to use for [MUSIC] but requires specifically a MemoryStickDuo, anything else will not work.
# You can have multiple video folders under MP_ROOT. Where normally you'd have a 100MNV01 folder, and put in all your MP4 videos, with the bogus firmware, you can have multiple videos named such as 100MNV02, 100MNV03, etc. This would allow you to be able to categorize the videos in some way. They all show up normally under the VIDEO category regardless.
# The ability to load executables via USB "usb:" was implemented (the same way as with Gameshare) but not called, this may have been planned to use with PS2 USB Communication early on.
# Wallpaper Theme Settings were in place but the API was not called, assets like the dialog/registry checks were already programmed.
# A check was in-place where a *.THM (MP4 Thumbnail / JPG) is detected in ms0:/MP_ROOT.
# The ability to download MP4 videos over WiFi (similar to gameshare) was implemented but not used. This may have been used in conjunction with the multiple video directories and the above thumbnail detection.
== Leftover Modules from Development ==
# A VSH module 'dlgsample_plugin.prx' was left in the firmware from the SCE firmware engineers, as a way to test dialogs in the firmware.
# Multiple kernel modules left in the firmware:
# rinit.prx (registry initialize), resets the registry/settings on the PSP. (As if you went to Reset Default Settings in the settings category), this is normally included in official PSP SDK setups under kmodule.
# loadcorei.prx (sceKernelLoaderCoreInternal), an internal development variation of sceLoaderCore (loadcore.prx), which includes several missing security checks like allowing plain PRX/ELFs to be loaded.
# rebooti.prx (sceKernelRebootInternal), an internal development variation of sceKernelReboot (reboot.prx) (unsure of what this does for now.)
Please note that all contributions to PSP Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PSP Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)
Retrieved from "http://www.psdevwiki.com/psp/1.00_Bogus_Firmware"