Various PS2 projects

https://github.com/ps2dev/ps2toolchain#requirements

 

Sorry, I forgot to mention that I already add the entries to PATH.

 

Did you close and open your console?

 

Thanks, I managed to build the project. I had to install PS2SDK again. But when I try to load it on PCSX2 it freezes with the following log messages:

Spoiler: LOG MESSAGE

HLE Host: Set 'host:' root path to: C:\Users\jhona\Desktop\COMPILADO NOVO\
Opening plugins...
Opening GS
Opening PAD
Opening SPU2
Current Renderer: Direct3D9 (Hardware mode)
Intel(R) HD Graphics 4000 (10.18.10.4252)
Opening CDVD
Opening USB
Opening FW
Opening DEV9
McdSlot 0 [File]: C:\Users\jhona\Documents\PCSX2\memcards\Mcd001.ps2
McdSlot 1 [File]: C:\Users\jhona\Documents\PCSX2\memcards\Mcd002.ps2
Plugins opened successfully.
Bios Found: USA v01.60(07/02/2002) Console
BIOS rom1 module not found, skipping...
BIOS rom2 module not found, skipping...
BIOS erom module not found, skipping...
# Initialize memory (rev:3.63, ctm:392Mhz, cpuclk:294Mhz detected)
PlayStation 2 ======== Hard reset boot
ROMGEN=2002-0207, IOP info (CPUID=1f, CACH_CONFIG=0, 2MB, IOP mode)
<20020207-164243,ROMconf,PS20160AC20020207.bin:11552>
# Total accessable memory size: 32 MB (B:2:8:0) (363:2:7c30)
# TLB spad=0 kernel=1:12 default=13:30 extended=31:38
# Initialize Start.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# Initialize Done.
EE DECI2 Manager version 0.06 Feb 7 2002 16:41:20
CPUID=2e20, BoardID=0, ROMGEN=2002-0207, 32M
found 49788 symbols
ELF (host:C:\Users\jhona\Desktop\COMPILADO NOVO\snes9x.elf) Game CRC = 0x01050B37, EntryPoint = 0x001000D8
IOP Realtime Kernel Ver.0.9.1
Copyright 1999 (C) Sony Computer Entertainment Inc.
Reboot service module.(99/11/10)
cdvd driver module version 0.1.1 (C)SCEI
Load File service.(99/11/05)
Multi Threaded Fileio module.(99/11/15)
iop heap service (99/11/03)
loadelf: fname host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf secname all
loadelf version 3.30
Input ELF format filename = host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf
0 00100000 003a6f88 ...........................................................
Loaded, host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf
start address 0x1000d8
gp address 00000000
# Restart Without Memory Clear.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize Scratch Pad ...
# Restart Without Memory Clear Done.
read/write allocate memory 4000
argv[0] = host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf
(EE pc:00303078) TLB Miss, addr=0x0 [load]
(EE pc:0030315C) TLB Miss, addr=0x0 [load]
(EE pc:00302E30) TLB Miss, addr=0x0 [load]
Get Reboot Request From EE
ROM directory not found
PlayStation 2 ======== Update rebooting..
PlayStation 2 ======== Update reboot complete
IOP Realtime Kernel Ver.0.9.1
Copyright 1999 (C) Sony Computer Entertainment Inc.
Reboot service module.(99/11/10)
Load File service.(99/11/05)
Multi Threaded Fileio module.(99/11/15)
iop heap service (99/11/03)

 

Looks like null pointer read to me.

Did you try it on a real PS2?

 

I didn't try it yet, My PS2 is broken...

Is there any way to debug this?

 

The usual ways:

• Leave debug symbols in the ELF (don't add the -s linker option nor strip with ee-strip) and compile with the -g compiler option. Use ee-addr2line to get the line number of the fault from the exception program counter (EPC).
• Add more printf() statements around, to locate the point of failure.
• Do a static check of your code, to look out for bad coding practices and mistakes. Variables should always be initialized somewhere before use.

 

Depending on what version of pcsx2 you are using it may not run at all. For a long time when using the latest dev builds and homebrew that used host: did not run as host is/was not a valid device in pcsx2.

 

Do you know what the commands are dsnet is sending to the ps2 for each function?

 

Yes, I do. Not everything is documented well, however, as it was just a quick glance.

 

Cool. Is it possible to send the commands via serial mod?

 

Commands are usually sent through the MRP device (the interplane of the TOOL connecting the PC and the PS2) or through the network (for RDB on retail/TEST PS2 or dsnetm). It may be possible to use Kermit's dsnetm to also send commands through IEEE1394 or EE SIO.

 

Retdec has added support for a few more MIPS instructions: https://github.com/avast-tl/retdec/commit/bfd6efb255f8bcaf60cba524ae56f66afdcf5645

Debug information does wonders for the output of Retdec. The dsnet binaries do not have the STABS debug information stripped, but retdec does not support STABS; only DWARF and PDB are supported.
No debug information:

Code:

// Address range: 0x804983b - 0x80498ef
int32_t parse_memlimit(int32_t a1) {
    // 0x804983b
    char v1;
    g6 = v1;
    char * str;
    int32_t len = strlen(str); // 0x8049857
    int32_t v2;
    unsigned char v3;
    if (len == 0) {
        // 0x80498ad
        v2 = str_to_uint64(a1, str, 0, 0, -1, -1);
        // branch -> 0x80498cc
        // 0x80498cc
        return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 0);
    }
    int32_t v4 = len - 1; // 0x804986b
    g6 = v4;
    char * v5 = (char *)(v4 + (int32_t)str); // 0x8049873
    if (*v5 != 37) {
        // 0x80498ad
        v2 = str_to_uint64(a1, str, 0, 0, -1, -1);
        // branch -> 0x80498cc
        // 0x80498cc
        return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 0);
    }
    // 0x804987a
    g6 = v4;
    *v5 = 0;
    int32_t v6;
    v2 = str_to_uint64(v6, str, 1, 0, 100, 0);
    // branch -> 0x80498cc
    // 0x80498cc
    return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 1);
}

Yes debug information:

Code:

// From module:   /home/vagrant/xz-5.2.4/src/xz/args.c
// Address range: 0x804983b - 0x80498ef
// Line range:    34 - 55
void parse_memlimit(char * name, char * name_percentage, char * str, bool set_compress, bool set_decompress) {
    char * v1 = str; // bp+12
    g5 = set_compress;
    int32_t len = strlen(str); // 0x8049857
    int64_t v2; // 0x80498be
    if (len == 0) {
        // 0x80498ad
        v2 = str_to_uint64(name, str, 0, 0);
        // branch -> 0x80498cc
        // 0x80498cc
        hardware_memlimit_set((int64_t)(int32_t)v2, g5 % 2 != 0, set_compress, set_decompress);
        return;
    }
    int32_t v3 = len - 1; // 0x804986b
    g5 = v3;
    char * v4 = (char *)(v3 + (int32_t)str); // 0x8049873
    if (*v4 != 37) {
        // 0x80498ad
        v2 = str_to_uint64(name, str, 0, 0);
        // branch -> 0x80498cc
        // 0x80498cc
        hardware_memlimit_set((int64_t)(int32_t)v2, g5 % 2 != 0, set_compress, set_decompress);
        return;
    }
    // 0x804987a
    g5 = v3;
    *v4 = 0;
    int32_t v5 = *(int32_t *)&v1; // 0x804989714
    int32_t v6 = *(int32_t *)&name_percentage; // 0x804989a15
    int32_t v7 = str_to_uint64((char *)v6, (char *)v5, 1, 0);
    // branch -> 0x80498cc
    // 0x80498cc
    hardware_memlimit_set((int64_t)v7, g5 % 2 != 0, set_compress, set_decompress);
}

Notice the readable function variable names, correct types, and correct number of arguments. Also, note the errors with 64-bit integers.
Original source code:

Code:

static void
parse_memlimit(const char *name, const char *name_percentage, char *str,
bool set_compress, bool set_decompress)
{
bool is_percentage = false;
uint64_t value;
const size_t len = strlen(str);
if (len > 0 && str[len - 1] == '%') {
str[len - 1] = '\0';
is_percentage = true;
value = str_to_uint64(name_percentage, str, 1, 100);
} else {
// On 32-bit systems, SIZE_MAX would make more sense than
// UINT64_MAX. But use UINT64_MAX still so that scripts
// that assume > 4 GiB values don't break.
value = str_to_uint64(name, str, 0, UINT64_MAX);
}
hardware_memlimit_set(
value, set_compress, set_decompress, is_percentage);
return;
}

I know that some games had symbols left in their executables, but has there been any case of IOP modules with symbols in their executables (other than OSDSND in early ROMs)?

 

How did you get the stab information to pass to retdec? Also retdec only supports 32 bit executables which is why there are errors with the 64 bit integers. I think

 

It's a decompilation of xz as I used as an example, not the dsnet tools.
Also, in the example with no debug information, the 64 bit integer is split into 2 32 bit integers.

 

I see. I didn't look to closely as I just woke up. I had previously looked into extracting the stab information and formatting it to pass to retdec but came up empty handed. Stab doesn't seem to be documented too well which is praprobaa reason for the lack of support.

 

If you meant Sony IOP modules, then no... they've been pretty consistent from what I have seen. Maybe it was also because they designed their modules to have the most correct behaviour with as little space wasted as possible, so as to not add onto resource overhead. Which makes sense, since their modules go into ROM and also make up a SDK.

The OSDSND case might have been because they were rushing to complete the SPU2 and its libraries. OSDSND is also known as rspu2drv, the tentative sound library.
The only other module that I've seen which is abnormally large, is ILINK.IRX. But I never found one with symbols. It has a lot of code, seemingly because they compiled with O0 and have assertions everywhere.

On the other hand, there are IOP modules with debugging information within games. Like with plain ELFs, they could have symbol information stripped out (or not). Sometimes we get lucky and a bugged game still has symbols left behind.

 

You two gentlemen are aware that I have been working on the translation port of the PS2 version of Fate/Stay Night [Realta Nua]. The reason I asked about the stabs information is because that while pcsx2 and ps2dis don't see the the symbol table there are in fact mangled c++ symbols present in the game. I am fairly certain that there is also stab information present but I have no idea how to get at it or even how to put it to use.

Also the actual point of replying which I forgot. There are a handful of instructions the PS2 uses that capstone doesn't have. Notably the paddu instruction that most games start out using to clear the system registers. When capstone doesn't know of an instruction retdec simply skips over it and pretends it wasn't there.

 

To check the if there is STABS information, use objdump -h /path/to/executable/file and check for .stabs section. If it is there, that means the file has STABS debugging information.

I noticed that Retdec doesn't decompile the newer OSDSYS correctly; it just decompiles 2 functions.
This issue might help in implementing more instructions: https://github.com/avast-tl/retdec/issues/393

For HOSDSYS, it seems like the first 512 bytes of FNTOSD/ICOIMAGE/JISUCS/SKBIMAGE/SNDIMAGE/TEXIMAGE are obfuscated. The rest after that look like a decrypted RESET/IOPRP structure. Anyone know how to deobfuscate the first 512 bytes? I couldn't find any cross-references.

 

It does the same thing for ps2-packer compressed elfs. This is because it doesn't know how to detect compressed ps2 elfs nor how to unpack them. I noticed this yesterday when attempting to decompile esr. I had to manually unpack it with the old ps2unpacker and pull some parts from memory in pcsx2.

Unfortunately as far as that issue on the retdec page goes I definitely agree with their standing on only wishing to have standard instructions implemented. I had actually attempted to write my own decompiler using capstone for the vita and ps2 but have shelved it at the moment. One could create a fork of retdec and add the instructions but I doubt it would ever be merged. As long as the instruction translates to llvm ir nicely it should work out.