PS2 SLPM file data question: What is this stuff specifically?

Discussion in 'Technical Discussion' started by Travelsonic, Sep 14, 2013.

  1. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    I was looking at the end of the SLPM file for DDRMAX2 [JP, duh], and noticed something I am curiou about.

    Loaded the file into wordpad, made a png w/ a couple of screengrabs, since I'm too lazy to copy+paste ascii in FRHed.

    [​IMG]

    I wonder, are these what I think these are, variable labels?

    If so, there seems to be a small fair-ish amount of data between each ascii string - wonder if it is anything that may be useful in incorporating these in my disassembly of DDRMAX2's SLPM file [the disassembly leaving out all these labels]?
     
  2. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    0
    0
    Writing my own MD/Genesis sound driver :D
    What is the filename, slpm####.## (where ## are some numbers)?
     
  3. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    SLPM652.77

    I also noticed the other US and JP releases from DDRMAX to DDR EXTREME had a shitload of these at the end of the respective files.

    For MAX2JP [SLPM65277] at least, look at 0x17f5f8 and onward.
     
  4. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    0
    0
    Writing my own MD/Genesis sound driver :D
    Those are the main executable, and are standard ELF binaries that you can just load into IDA to get an automated disassembly (or use a PS2-specific disassembler which works differently, your choice). Not sure what that particular part of the file is, but it would be funny if the games were not stripped...
     
  5. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    Been using IDA Pro, it is really cool.

    noticed this line at 0x17f5f8 for the SLPM file:

    shstrtab debug line strtab symtab comment reginfo

    After which is all the crap that made me impulsively start this thread.

    I wonder.... if they actually left the debug information in - including symbol tables [and this is what I'm looking at]. Those strings above, combined with all those variable names being listed make me think so.


    Wouldn't surprise me, beatmania Best Hits for the PS1 used a dummy.bin file to pad out the disk size that actually was a .lzh file containing the source code to beatmania 5th Mix - and a version of the code that was not only close to the final release, but with some tweaking one that could readily be compiled by anyone competent. [​IMG][​IMG][​IMG][​IMG][​IMG]
     
  6. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    [pardon double post]
    Doing some research, I found this page - and according to this guy,
    - which means that, assuming this is true, that it is most likely that Konami's Dance Dance Revolution series - including JP and US MAX, MAX2, EXTREME, and Dancing Stage mixes from that time, have that/this is what I found.

    Squeegasm! :specialed:/>/>/> :specialed:/>/>/> :specialed:/>/>/> :specialed:/>/>/>
     
  7. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    [PARDON TRIPLE POST please]

    Assuming this is the symbol table, which I can safely say is the best bet, what would be the best means of interpreting the other data besides the literal strings present, unraveling so to speak how the data is laid out, if it is even possible?
     
  8. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    0
    0
    Writing my own MD/Genesis sound driver :D
    If it's a standard ELF symbol table, IDA should have taken care of it for you (check to see if any function names are filled in, or even do a text search for some of the strings)... otherwise the format is known. If it's not standard, then...
     
  9. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    From what I can tell, it does follow the standards for the ELF format - so I guess that is excellent news. :specialed:
     
  10. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    Just got some screenies up on the blog I started for hacking DDR games, so maybe this will be a better look at the data I'm trying to decode (screengrabs from FRHed, rather)

    [sup][sup][​IMG][/sup][/sup]
    [sup][sup][​IMG][/sup][/sup]
     
  11. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,291
    6
    18
    wouldn't you like to know
    Super Guitar Hero II
    Necropost, but that is definitely a symbol table. Should end up being useful for disassembly. As PS2 uses standard ELF files, if you have access to a system with GNU binutils, you can use objdump to dump the relevant info (along with any possible relocation table, which can provide further insight into function names).

    Been looking into ELFs recently as I found an ELF on the Beatles RB Wii disc (normally, Wii uses .DOL format which is much simpler than ELF), and it actually has symbols as well. Also found that Frequency rev179 also has an unstripped binary, but every retail Harmonix PS2 game I have looked at has stripped ELFs.
     
  12. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    A member of a music game website, and game hacking website, and I briefly worked together to hack some Dance Dance Revolution Ps2 games a couple of years ago, and he thinks this **may** be part of left over debugging data, either STAB or DWARF format. Are there any tools that can attempt to reverse-engineer leftover dwarf data into a readable (or semi-readable) form?

    Interestingly, this data is left over in all Dance Dance Revolution PS2 titles. In DDRMAX2 -DanceDanceRevlution 7thMIX-, this data approximately 375.224 kilobytes. It would be nice to see if we can get that data into a readable state, as it would help me so much with my efforts to reverse engineer the PS2 Dance Dance Revolution series.
     
  13. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,291
    6
    18
    wouldn't you like to know
    Super Guitar Hero II
    That much I'm not sure about. It would certainly help with disassembly, in the hands of someone knowledgeable in PS2 internals. The symbols basically tell where each function is in the object file, as well as the functions' names. I'm not knowledgeable about STAB or DWARF, so I don't know. I did see reference to DWARF in the usage information for both objdump and readelf, so if you have access to those tools (either on an actual Unix-based system, or via something like Cygwin or WSL) then you may be able to make use of that data.

    If you can provide me with copies of any ELFs in question, I could run them through these tools and provide you with the output. At the very least, it should match up those function names with their locations both in the ELF file, as well as their actual location in PS2 RAM.

    Edit: I read the thread that you linked. IDA should be picking up on the symbol table, so you should already be making use of it. This may also be of help with IDA.
     
  14. Travelsonic

    Travelsonic

    Member
    816
    14
    18
  15. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,291
    6
    18
    wouldn't you like to know
    Super Guitar Hero II
    According to these tools, I was wrong and that's not a symbol table?

    Code (Text):
    1. ELF Header:
    2.   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
    3.   Class:                             ELF32
    4.   Data:                              2's complement, little endian
    5.   Version:                           1 (current)
    6.   OS/ABI:                            UNIX - System V
    7.   ABI Version:                       0
    8.   Type:                              EXEC (Executable file)
    9.   Machine:                           MIPS R3000
    10.   Version:                           0x1
    11.   Entry point address:               0x100008
    12.   Start of program headers:          52 (bytes into file)
    13.   Start of section headers:          1944312 (bytes into file)
    14.   Flags:                             0x20924000, unknown CPU, eabi64, mips3
    15.   Size of this header:               52 (bytes)
    16.   Size of program headers:           32 (bytes)
    17.   Number of program headers:         2
    18.   Size of section headers:           40 (bytes)
    19.   Number of section headers:         10
    20.   Section header string table index: 1
    21.  
    22. Section Headers:
    23.   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
    24.   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
    25.   [ 1] .shstrtab         STRTAB          00000000 17f600 00003a 01      0   0  1
    26.   [ 2] .strtab           STRTAB          00000000 000000 000000 01      0   0  1
    27.   [ 3] .symtab           SYMTAB          00000000 000000 000000 10      2   0  1
    28.   [ 4]                   PROGBITS        00100000 000080 17f580 01 WAX  0   0 128
    29.   [ 5]                   PROGBITS        0068e200 17f600 000000 01  WA  0   0 16
    30.   [ 6] .debug            MIPS_DEBUG      00000000 17f640 048edc 01      0   0  1
    31.   [ 7] .line             MIPS_DEBUG      00000000 1c8520 012594 01      0   0  1
    32.   [ 8] .comment          PROGBITS        00000000 1daab4 00002b 01      0   0  1
    33.   [ 9] .reginfo          MIPS_REGINFO    00000000 1daae0 000018 01      0   0  4
    34. Key to Flags:
    35.   W (write), A (alloc), X (execute), M (merge), S (strings)
    36.   I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
    37.   O (extra OS processing required) o (OS specific), p (processor specific)
    38.  
    39. There are no section groups in this file.
    40.  
    41. Program Headers:
    42.   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    43.   LOAD           0x000080 0x00100000 0x00100000 0x17f580 0x58e200 RWE 0x80
    44.   LOAD           0x17f600 0x0068e200 0x0068e200 0x00000 0x00000 RW  0x10
    45.  
    46.  Section to Segment mapping:
    47.   Segment Sections...
    48.    00      
    49.    01      
    50.  
    51. There is no dynamic section in this file.
    52.  
    53. There are no relocations in this file.
    54.  
    55. The decoding of unwind sections for machine type MIPS R3000 is not currently supported.
    56.  
    57. Symbol table '.symtab' contains 0 entries:
    58.    Num:    Value  Size Type    Bind   Vis      Ndx Name
    59.  
    60. No version information found in this file.
    61.  
    As opposed to part of the same output when run on the unstripped ELF from Frequency revision 179:

    Code (Text):
    1. ELF Header:
    2.   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
    3.   Class:                             ELF32
    4.   Data:                              2's complement, little endian
    5.   Version:                           1 (current)
    6.   OS/ABI:                            UNIX - System V
    7.   ABI Version:                       0
    8.   Type:                              EXEC (Executable file)
    9.   Machine:                           MIPS R3000
    10.   Version:                           0x1
    11.   Entry point address:               0x469178
    12.   Start of program headers:          64 (bytes into file)
    13.   Start of section headers:          96 (bytes into file)
    14.   Flags:                             0x20924001, noreorder, unknown CPU, eabi64, mips3
    15.   Size of this header:               52 (bytes)
    16.   Size of program headers:           32 (bytes)
    17.   Number of program headers:         1
    18.   Size of section headers:           40 (bytes)
    19.   Number of section headers:         29
    20.   Section header string table index: 13
    21.  
    22. Section Headers:
    23.   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
    24.   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
    25.   [ 1] .text             PROGBITS        00100000 001000 5810d8 00  AX  0   0 64
    26.   [ 2] .vutext           PROGBITS        006810e0 5820e0 001880 00  AX  0   0 16
    27.   [ 3] .data             PROGBITS        00682980 583980 169c80 00  WA  0   0 64
    28.   [ 4] .rodata           PROGBITS        007ec600 6ed600 08e2dc 00   A  0   0 16
    29.   [ 5] .gcc_except_table PROGBITS        0087a8e0 77b8e0 02ce24 00  WA  0   0 16
    30.   [ 6] .ctors            PROGBITS        008a7704 7a8704 0003c0 00  WA  0   0  4
    31.   [ 7] .dtors            PROGBITS        008a7ac4 7a8ac4 0000e4 00  WA  0   0  4
    32.   [ 8] .frames           PROGBITS        008a7ba8 7a8ba8 000004 00  WA  0   0  4
    33.   [ 9] .scommon          NOBITS          008a7bb0 7a8bb0 000228 00 WAp  0   0 16
    34.   [10] .bss              NOBITS          008a7e00 7a8bc0 08302c 00  WA  0   0 64
    35.   [11] .reginfo          MIPS_REGINFO    00000000 7a8bc0 000018 00      0   0  4
    36.   [12] .mdebug           MIPS_DEBUG      00000000 7a8bd8 437502 00      0   0  4
    37.   [13] .shstrtab         STRTAB          00000000 be00da 0001f8 00      0   0  1
    38.   [14] .symtab           SYMTAB          00000000 be02d4 0477f0 10     15 7888  4
    39.   [15] .strtab           STRTAB          00000000 c27ac4 07c1e2 00      0   0  1
    40.   [16] .DVP.ovlytab      LOPROC+ffff420  00000000 ca3ca8 000084 00   W 17   0  4
    41.   [17] .DVP.ovlystrtab   STRTAB          00000000 ca3d2c 00015e 00   W  0   0  1
    42.   [18] .DVP.overlay..0x0.3155.101.0 LOPROC+ffff421  00000000 ca3e8a 000800 00  WX  0   0  1
    43.   [19] .DVP.overlay..unknvma.854443.451.1 LOPROC+ffff421  00000000 ca468a 0001b8 00  WX  0   0  1
    44.   [20] .DVP.overlay..0xc80.3155.104.2 LOPROC+ffff421  00000000 ca4842 0002c8 00  WX  0   0  1
    45.   [21] .DVP.overlay..0x1130.3155.107.3 LOPROC+ffff421  00000000 ca4b0a 0001f8 00  WX  0   0  1
    46.   [22] .DVP.overlay..0x15e0.3155.110.4 LOPROC+ffff421  00000000 ca4d02 000010 00  WX  0   0  1
    47.   [23] .DVP.overlay..0x1630.3155.113.5 LOPROC+ffff421  00000000 ca4d12 000138 00  WX  0   0  1
    48.   [24] .DVP.overlay..0x1950.3155.116.6 LOPROC+ffff421  00000000 ca4e4a 0001b8 00  WX  0   0  1
    49.   [25] .DVP.overlay..0x1c70.3155.119.7 LOPROC+ffff421  00000000 ca5002 000030 00  WX  0   0  1
    50.   [26] .DVP.overlay..0x1d10.3155.122.8 LOPROC+ffff421  00000000 ca5032 0000d0 00  WX  0   0  1
    51.   [27] .DVP.overlay..0x1ea0.3155.125.9 LOPROC+ffff421  00000000 ca5102 000518 00  WX  0   0  1
    52.   [28] .DVP.overlay..0x0.3155.144.10 LOPROC+ffff421  00000000 ca561a 000050 00  WX  0   0  1
    53. Key to Flags:
    54.   W (write), A (alloc), X (execute), M (merge), S (strings)
    55.   I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
    56.   O (extra OS processing required) o (OS specific), p (processor specific)
    57.  
    58. There are no section groups in this file.
    59.  
    60. Program Headers:
    61.   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    62.   LOAD           0x001000 0x00100000 0x00100000 0x7a7bac 0x7a7bac RWE 0x1000
    63.  
    64.  Section to Segment mapping:
    65.   Segment Sections...
    66.    00     .text .vutext .data .rodata .gcc_except_table .ctors .dtors .frames
    67.  
    68. There is no dynamic section in this file.
    69.  
    70. There are no relocations in this file.
    71.  
    72. The decoding of unwind sections for machine type MIPS R3000 is not currently supported.
    73.  
    74. Symbol table '.symtab' contains 18303 entries:
    75.    Num:    Value  Size Type    Bind   Vis      Ndx Name
    76.      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
    77.      1: 00100000     0 SECTION LOCAL  DEFAULT    1
    78.      2: 006810e0     0 SECTION LOCAL  DEFAULT    2
    79.      3: 00682980     0 SECTION LOCAL  DEFAULT    3
    80.      4: 007ec600     0 SECTION LOCAL  DEFAULT    4
    81.      5: 0087a8e0     0 SECTION LOCAL  DEFAULT    5
    82.      6: 008a7704     0 SECTION LOCAL  DEFAULT    6
    83.      7: 008a7ac4     0 SECTION LOCAL  DEFAULT    7
    84.      8: 008a7ba8     0 SECTION LOCAL  DEFAULT    8
    85.      9: 00080000     0 NOTYPE  LOCAL  DEFAULT    1 _stack_size
    86.     10: ffffffff     0 NOTYPE  LOCAL  DEFAULT    1 _heap_size
    87.  
    88. .
    89. .
    90. .
    91.  
    92.  18285: 00747010     8 OBJECT  GLOBAL DEFAULT    1 __tiw
    93.  18286: 005708c0    52 FUNC    GLOBAL DEFAULT    1 __tfw
    94.  18287: 00570888    52 FUNC    GLOBAL DEFAULT    1 __tfc
    95.  18288: 00747000     8 OBJECT  GLOBAL DEFAULT    1 __tib
    96.  18289: 00570850    52 FUNC    GLOBAL DEFAULT    1 __tfb
    97.  18290: 00746ff8     8 OBJECT  GLOBAL DEFAULT    1 __tis
    98.  18291: 00570818    52 FUNC    GLOBAL DEFAULT    1 __tfs
    99.  18292: 00747058     8 OBJECT  GLOBAL DEFAULT    1 __tiSc
    100.  18293: 00570ab8    52 FUNC    GLOBAL DEFAULT    1 __tfSc
    101.  18294: 00747050     8 OBJECT  GLOBAL DEFAULT    1 __tiUc
    102.  18295: 00570a80    52 FUNC    GLOBAL DEFAULT    1 __tfUc
    103.  18296: 00747048     8 OBJECT  GLOBAL DEFAULT    1 __tiUs
    104.  18297: 00570a48    52 FUNC    GLOBAL DEFAULT    1 __tfUs
    105.  18298: 00747040     8 OBJECT  GLOBAL DEFAULT    1 __tiUx
    106.  18299: 00570a10    52 FUNC    GLOBAL DEFAULT    1 __tfUx
    107.  18300: 00747038     8 OBJECT  GLOBAL DEFAULT    1 __tiUl
    108.  18301: 005709d8    52 FUNC    GLOBAL DEFAULT    1 __tfUl
    109.  18302: 00747060     0 OBJECT  GLOBAL DEFAULT    1 _GLOBAL_$F$before__C9type_infoRC9type_info
    110.  
    111. No version information found in this file.
    Symbol names in the Frequency ELF seem to be mangled, meaning that it was likely developed in C++.

    Still trying to wrap my head around "modern" development processes in general. So I'm back to being not sure what that data actually is. It's not a symbol table, at least not directly.
     
  16. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    Hmm, for me to look up what I can on the DWARF debugging format, ask around, as there is something not being recognized by the tools you used that is still legit worth investigating, looking at. Odd.
     
  17. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    (pardon the double-post) It is baffling, I think the data is still some sort of symbol data - it HAS To be, those names absolutely look like variable names (and helped me understand structures of data I've found in the game).

    Silly Q: Working with a disassembly, I wonder what would be the best way of finding where functions and code for specific objects begin/end, so I can split off specific objects into separate ASM files for a split disassembly I am going to try to create.
     
  18. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,291
    6
    18
    wouldn't you like to know
    Super Guitar Hero II
    There are similar strings in the GH games (there, they're found in the .rodata segment), some of which are referenced in the code and some of which don't seem to be, or I don't have them marked as code. It would be nice if PCSX2 could output a code/data log that we could import into IDA.
     
  19. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    Speaking of this data, on page 93 of this document on DWARF, I noticed Compilation Unit 1 - .debug has a structure remarkably similar to the data I am looking at in the DDRMAX2 ELF, which I wish I had noticed earlier, as now I think I may have another point to work off of.
     
  20. Travelsonic

    Travelsonic

    Member
    816
    14
    18
    So, having time free now that my semester is over (and I've graduated yay!), I've gone back and looked at this data again. Definitely function names, and variable names - including names for data structures. Been trying to find info on this particular thing in whatever DWARF documentation (DWARF 2.0 if I recall correctly), and working with a disassembly + a PS2 emulator with debugger has allowed me to give you educated guesses as to which functions, but damn is it frustrating.