- Author: Swingflip (On behalf of ModMyClassic)
- Date: 19th December 2018
- Links: https://modmyclassic.com // https://discordapp.com/invite/8gygsrw
This is a brief document to outline the initial design of the BleemSync payload for the purpose of giving devs an understanding of how BleemSync is deployed and outline any areas of the design which has room for improvement.
BleemSync is an application that will reside on both end user's consoles and computers. The main purpose of BleemSync is to allow for safe and easy deployment of 3rd party scripts, emulators and roms to extend the original functionality of the PlayStation Classic.
There are effectively two parts of BleemSync. The BleemSync UI that sits on the end user's computer (Win, Mac, Linux) and the BleemSync Payload. Both elements are branded and considered just as "BleemSync" at the time of writing this document.
This document will only cover the payload part of BleemSync with loose references to the BleemSync UI.
During production, Sony included a usb updater daemon on the console which checks for an update payload that's been encrypted with gpg using a symmetric encryption, Sony left the keys and passphrase for the encryption on the console which allowed for arbitrary code execution.
Using these keys and passphrase, we are able to generate and sign our own encrypted payloads which can be executed on the console via an USB drive connected to the 2nd player controller port.
The initial design only has the encrypted payload do minor code vetting on the custom scripts and executes the BleemSync Executor which allows for full transparency and the ability to modify execution routines on the fly. (I.e. you don't need to rebuild and encrypt a payload if you want to change something within the execution routine)
The design launches three separate files to execute the "hack". The initial encrypted payload is loaded by Sony's built in USB updater daemon.
(Encrypted Payload) --> (Execute) --> (Execute-child)
Within execute (the parent) a user can dictate the what and in what order functions are run during the boot of the PlayStation Classic. This is achieved by setting command line arguments which are then passed onto the execute-child where it will execute functions dictated by its parent.
This allows for greater flexibility allowing users to modify their boot routine to include/exclude certain functions to tailor their headerless boot sequence. This is not to say that the execute-child won't potentially load up an SDL application with GUI to allow users to select what application they wish to boot to. (i.e. RetroArch or Stock PlayStation Classic UI)
It should also be noted that the entire BleemSync Payload contains function libraries, supplementary scripts/apps and a central configuration file. This will be covered later in the document.
Example of headerless boot of BleemSync Payload
- User connects USB with complete BleemSync Payload loaded
- Sony's USB Updater routine detects and mounts the USB in 2nd controller port
- Detects encrypted payload
/media/6eab3455-d7a9-4cfd-8e0c-f41d3e61b151/LAPPS.BINand executes it - Encrypted payload runs some basic functions and sanitises BleemSync payload (i.e. possible modification from end users might have bad line terminators) and then simply executes
/media/bleemsync/bin/execute - execute loads the given configuration, loads the given execution sequence, carries out minor maintenance and then executes
/media/bleemsync/bin/execute-childpassing the appropriate commandline arguments. - execute-child parses the passed arguments, loads configuration and function libraries and executes the functions in the order dictated to it.
Most of the time, the last thing to execute will be the actual BleemSync on console application. However end users are able to run different routines like, headerless backup and restore, development and debugging routines or executing initial hack routines. (i.e. safely remove USB check, enabling TELNET+FTP, injecting a safe restore method etc)
All of the above is possible by modifying the enabled commandline arguments within execute. While a user can just simply modify this file manually using a text editor for a headerless solution, the idea is that the boot routine will be managed and controlled using the BleemSync UI from the Computer.
One of the main design goals for the payload is that it can be used in a multitude of different deployment methods. The initial and main method will be from USB but it needs to be designed in a way that it can be simply loaded on to the console's EMMC (if/when we are able to flash the kernel with overlayFS support!)
Taking in consideration of the above goal, the proposed file structure for the payload would be to follow general UNIX filesystem guidelines. The entire BleemSync payload therefore will be contained within /media/bleemsync or /opt/bleemsync if it was located on the PlayStation Classic file system.
The bleemsync payload is structured using general UNIX filesystem guidelines meaning that the payload could eventually be overlayed on-top of an existing filesystem using overlayFS. This being said, binaries go into bin/ scripts, configurations etc go into etc/, any additional shared libraries go to usr/lib/ and so forth.
The etc/ directory and how it's used
As of writting this document the etc/ directory is split up in to 3 different directories:
CFG- This contains the configuration file(s) for bleemsync in shell format. (.cfgfor configs,.queuefor execution queue filesFUNC- These are function libraries used throughout the entire BleemSync deployment on the console. Please ensure to follow standard and logging standards. Functions should be designed in the sense that they can be run individually from the commandline. They should be self sufficient but they are able to source variables frombleemsync.cfgSUP- (Supplementary scripts) These are for supplementary scripts that can be used within function libraries and a commandline but due to their nature it is best to break it away from a function library into it's own seperate script for some reason or another. (i.e. very large script, messy code etc)
Final note on coding policies
When writing code for the project please refer to the existing scripts, files and apps in the project. If there is something that doesn't exist and you are wanting to implement it, just check in with one of the devs before implementation. This way we are able to ensure quality control and ensure that code being pushed to the project has been sense checked.
If you wish to take on one of these tasks please drop a message to one of the devs so we know who is working on what
- Simplify Execution script and overhaul slightly (swingflip doing)
- Finish off sanitising functionality within encrypted payload (swingflip doing)
- Finish off safe USB/TELNET/FTP hack
- Write a simple headerless recovery script that can be injected into the recovery partition
- Write up folder functions for the Sony UI and implement into bleemsync func library
- Include latest BleemSync codeset into the new deployment
- Code up the BleemSync PC UI (DoctorDalek doing)
- Finish off BleemSync on console SDL application (CompCom)
- Finish off and add RetroArch build and Cores for release (CompCom)
- Get imagery sorted for the UIs
- Add in extra functions into the function library to increase functionality
- Work on a simple modchip with resistor to remove 100ma cap on front USBs
- Work out simple way to boot into recovery mode (Partition 8)
- Add in Bluetooth support and WPA Supplicant
- Work out a way to flash kernel safely and build 64 bit kernel with overlayFS support
- Get website and wiki up and running
- Get forum up and running
- Something else I forgot...
Just ask us for advice on the discord above. If there is stuff you wish to add to the list then just let me know or do a PR
