>>1839351

ну и да, зачем ты какие-то там сектора пердолишь, я не понимаю, на всех дисках плойки один и тот же формат - исполняемый elf файл с именем в виде сосоневского кода релиза и system.cnf, где биосу указывается какой файл читать.

XXXX_NNN.NN (Boot-Executable) (filename specified in SYSTEM.CNF)
FILENAME.EXE (General-Purpose Executable)
PSX executables are having an 800h-byte header, followed by the code/data.

000h-007h ASCII ID "PS-X EXE"
008h-00Fh Zerofilled
010h Initial PC (usually 80010000h, or higher)
014h Initial GP/R28 (usually 0)
018h Destination Address in RAM (usually 80010000h, or higher)
01Ch Filesize (must be N*800h) (excluding 800h-byte header)
020h Unknown/Unused (usually 0)
024h Unknown/Unused (usually 0)
028h Memfill Start Address (usually 0) (when below Size=None)
02Ch Memfill Size in bytes (usually 0) (0=None)
030h Initial SP/R29 & FP/R30 Base (usually 801FFFF0h) (or 0=None)
034h Initial SP/R29 & FP/R30 Offs (usually 0, added to above Base)
038h-04Bh Reserved for A(43h) Function (should be zerofilled in exefile)
04Ch-xxxh ASCII marker
"Sony Computer Entertainment Inc. for Japan area"
"Sony Computer Entertainment Inc. for Europe area"
"Sony Computer Entertainment Inc. for North America area"
(or often zerofilled in some homebrew files)
(the BIOS doesn't verify this string, and boots fine without it)
xxxh-7FFh Zerofilled
800h... Code/Data (loaded to entry[018h] and up)

The code/data is simply loaded to the specified destination address, ie. unlike as in MSDOS .EXE files, there is no relocation info in the header.
Note: In bootfiles, SP is usually 801FFFF0h (ie. not 801FFF00h as in system.cnf). When SP is 0, the unmodified caller's stack is used. In most cases (except when manually calling DoExecute), the stack values in the exeheader seem to be ignored though (eg. replaced by the SYSTEM.CNF value).
The memfill region is zerofilled by a "relative" fast word-by-word fill (so address and size must be multiples of 4) (despite of the word-by-word filling, still it's SLOW because the memfill executes in uncached slow ROM).
The reserved region at [038h-04Bh] is internally used by the BIOS to memorize the caller's RA,SP,R30,R28,R16 registers (for some bizarre reason, this information is saved in the exe header, rather than on the caller's stack).
Additionally to the initial PC,R28,SP,R30 values that are contained in the header, two parameter values are passed to the executable (in R4 and R5 registers) (however, usually that values are simply R4=1 and R5=0).
Like normal functions, the executable can return control to the caller by jumping to the incoming RA address (provided that it hasn't destroyed the stack or other important memory locations, and that it has pushed/popped all registers) (returning works only for non-boot executables; if the boot executable returns to the BIOS, then the BIOS will simply lockup itself by calling the "SystemErrorBootOrDiskFailure" function.

The PSX uses the standard CDROM ISO9660 filesystem without any encryption (ie. you can put an original PSX CDROM into a DOS/Windows computer, and view the content of the files in text or hex editors without problems).

>>1853372

>Я хочу написать программу, которая инжектит программу (не асм стаб, а целую программу со всеми импортами SOшек) в адресное пространство другой программы, насколько это заебисто?

Примерно так (только на ассемблере) (где pid - идентификатор процесса):
Ну и потребуется рут, в обязательном порядке.

Для каждой архитектуры свои заморочки + есть вероятность соснуть тунца с ASLR

#include <sys/ptrace.h>
#include <stdio.h>

char file[64];

sprintf(file, "/proc/%ld/mem", (long)pid);

int fd = open(file, O_RDWR);

ptrace(PTRACE_ATTACH, pid, 0, 0);

waitpid(pid, NULL, 0);

off_t addr = ...; // target process address
pread(fd, &value, sizeof(value), addr);
// or
pwrite(fd, &value, sizeof(value), addr);

ptrace(PTRACE_DETACH, pid, 0, 0);