[Travelsonic]

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.



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]?

This post has been edited by Travelsonic: 14 September 2013 - 12:46 AM

[Andlabs]

What is the filename, slpm####.## (where ## are some numbers)?

[Travelsonic]

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.

This post has been edited by Travelsonic: 14 September 2013 - 11:52 AM

[Andlabs]

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...

[Travelsonic]

Andlabs, on 14 September 2013 - 12:00 PM, said:

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...

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.

This post has been edited by Travelsonic: 14 September 2013 - 12:30 PM

[Travelsonic]

[pardon double post]
Doing some research, I found this page - and according to this guy,

Quote

"As a bonus, tons of PS2 ELF binaries leave their symbol table fully intact."

- 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! />/>/> />/>/> />/>/> />/>/>

This post has been edited by Travelsonic: 14 September 2013 - 01:33 PM

[Travelsonic]

[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?

[Andlabs]

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...

This post has been edited by Andlabs: 16 September 2013 - 01:59 AM

[Travelsonic]

From what I can tell, it does follow the standards for the ELF format - so I guess that is excellent news.

[Travelsonic]

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)

[LocalH]

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.

[Travelsonic]

LocalH, on 07 March 2018 - 03:37 PM, said:

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.

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.

This post has been edited by Travelsonic: 08 March 2018 - 11:04 AM

[LocalH]

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.

This post has been edited by LocalH: 12 March 2018 - 01:36 PM

[Travelsonic]

Assuming I didn't fuck things up in attempting to create direct links to Google Drive files...
A link to a file containing just the debugging data
A link to the DDRMAX2 -DanceDanceRevolution 7thMIX- ELF (SLPM_652.77) - the data found in the file from the first link will be in the ELF - I just copied the data to a separate file in case it was easier to sift through - versus having to go to the point in the file where that data began, and then sift through it.

This post has been edited by Travelsonic: 13 March 2018 - 09:17 AM

[LocalH]

According to these tools, I was wrong and that's not a symbol table?

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x100008
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1944312 (bytes into file)
  Flags:                             0x20924000, unknown CPU, eabi64, mips3
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         10
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .shstrtab         STRTAB          00000000 17f600 00003a 01      0   0  1
  [ 2] .strtab           STRTAB          00000000 000000 000000 01      0   0  1
  [ 3] .symtab           SYMTAB          00000000 000000 000000 10      2   0  1
  [ 4]                   PROGBITS        00100000 000080 17f580 01 WAX  0   0 128
  [ 5]                   PROGBITS        0068e200 17f600 000000 01  WA  0   0 16
  [ 6] .debug            MIPS_DEBUG      00000000 17f640 048edc 01      0   0  1
  [ 7] .line             MIPS_DEBUG      00000000 1c8520 012594 01      0   0  1
  [ 8] .comment          PROGBITS        00000000 1daab4 00002b 01      0   0  1
  [ 9] .reginfo          MIPS_REGINFO    00000000 1daae0 000018 01      0   0  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x00100000 0x00100000 0x17f580 0x58e200 RWE 0x80
  LOAD           0x17f600 0x0068e200 0x0068e200 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      
   01      

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type MIPS R3000 is not currently supported.

Symbol table '.symtab' contains 0 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name

No version information found in this file.

As opposed to part of the same output when run on the unstripped ELF from Frequency revision 179:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x469178
  Start of program headers:          64 (bytes into file)
  Start of section headers:          96 (bytes into file)
  Flags:                             0x20924001, noreorder, unknown CPU, eabi64, mips3
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         29
  Section header string table index: 13

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00100000 001000 5810d8 00  AX  0   0 64
  [ 2] .vutext           PROGBITS        006810e0 5820e0 001880 00  AX  0   0 16
  [ 3] .data             PROGBITS        00682980 583980 169c80 00  WA  0   0 64
  [ 4] .rodata           PROGBITS        007ec600 6ed600 08e2dc 00   A  0   0 16
  [ 5] .gcc_except_table PROGBITS        0087a8e0 77b8e0 02ce24 00  WA  0   0 16
  [ 6] .ctors            PROGBITS        008a7704 7a8704 0003c0 00  WA  0   0  4
  [ 7] .dtors            PROGBITS        008a7ac4 7a8ac4 0000e4 00  WA  0   0  4
  [ 8] .frames           PROGBITS        008a7ba8 7a8ba8 000004 00  WA  0   0  4
  [ 9] .scommon          NOBITS          008a7bb0 7a8bb0 000228 00 WAp  0   0 16
  [10] .bss              NOBITS          008a7e00 7a8bc0 08302c 00  WA  0   0 64
  [11] .reginfo          MIPS_REGINFO    00000000 7a8bc0 000018 00      0   0  4
  [12] .mdebug           MIPS_DEBUG      00000000 7a8bd8 437502 00      0   0  4
  [13] .shstrtab         STRTAB          00000000 be00da 0001f8 00      0   0  1
  [14] .symtab           SYMTAB          00000000 be02d4 0477f0 10     15 7888  4
  [15] .strtab           STRTAB          00000000 c27ac4 07c1e2 00      0   0  1
  [16] .DVP.ovlytab      LOPROC+ffff420  00000000 ca3ca8 000084 00   W 17   0  4
  [17] .DVP.ovlystrtab   STRTAB          00000000 ca3d2c 00015e 00   W  0   0  1
  [18] .DVP.overlay..0x0.3155.101.0 LOPROC+ffff421  00000000 ca3e8a 000800 00  WX  0   0  1
  [19] .DVP.overlay..unknvma.854443.451.1 LOPROC+ffff421  00000000 ca468a 0001b8 00  WX  0   0  1
  [20] .DVP.overlay..0xc80.3155.104.2 LOPROC+ffff421  00000000 ca4842 0002c8 00  WX  0   0  1
  [21] .DVP.overlay..0x1130.3155.107.3 LOPROC+ffff421  00000000 ca4b0a 0001f8 00  WX  0   0  1
  [22] .DVP.overlay..0x15e0.3155.110.4 LOPROC+ffff421  00000000 ca4d02 000010 00  WX  0   0  1
  [23] .DVP.overlay..0x1630.3155.113.5 LOPROC+ffff421  00000000 ca4d12 000138 00  WX  0   0  1
  [24] .DVP.overlay..0x1950.3155.116.6 LOPROC+ffff421  00000000 ca4e4a 0001b8 00  WX  0   0  1
  [25] .DVP.overlay..0x1c70.3155.119.7 LOPROC+ffff421  00000000 ca5002 000030 00  WX  0   0  1
  [26] .DVP.overlay..0x1d10.3155.122.8 LOPROC+ffff421  00000000 ca5032 0000d0 00  WX  0   0  1
  [27] .DVP.overlay..0x1ea0.3155.125.9 LOPROC+ffff421  00000000 ca5102 000518 00  WX  0   0  1
  [28] .DVP.overlay..0x0.3155.144.10 LOPROC+ffff421  00000000 ca561a 000050 00  WX  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00100000 0x00100000 0x7a7bac 0x7a7bac RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text .vutext .data .rodata .gcc_except_table .ctors .dtors .frames 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type MIPS R3000 is not currently supported.

Symbol table '.symtab' contains 18303 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00100000     0 SECTION LOCAL  DEFAULT    1 
     2: 006810e0     0 SECTION LOCAL  DEFAULT    2 
     3: 00682980     0 SECTION LOCAL  DEFAULT    3 
     4: 007ec600     0 SECTION LOCAL  DEFAULT    4 
     5: 0087a8e0     0 SECTION LOCAL  DEFAULT    5 
     6: 008a7704     0 SECTION LOCAL  DEFAULT    6 
     7: 008a7ac4     0 SECTION LOCAL  DEFAULT    7 
     8: 008a7ba8     0 SECTION LOCAL  DEFAULT    8 
     9: 00080000     0 NOTYPE  LOCAL  DEFAULT    1 _stack_size
    10: ffffffff     0 NOTYPE  LOCAL  DEFAULT    1 _heap_size

.
.
.

 18285: 00747010     8 OBJECT  GLOBAL DEFAULT    1 __tiw
 18286: 005708c0    52 FUNC    GLOBAL DEFAULT    1 __tfw
 18287: 00570888    52 FUNC    GLOBAL DEFAULT    1 __tfc
 18288: 00747000     8 OBJECT  GLOBAL DEFAULT    1 __tib
 18289: 00570850    52 FUNC    GLOBAL DEFAULT    1 __tfb
 18290: 00746ff8     8 OBJECT  GLOBAL DEFAULT    1 __tis
 18291: 00570818    52 FUNC    GLOBAL DEFAULT    1 __tfs
 18292: 00747058     8 OBJECT  GLOBAL DEFAULT    1 __tiSc
 18293: 00570ab8    52 FUNC    GLOBAL DEFAULT    1 __tfSc
 18294: 00747050     8 OBJECT  GLOBAL DEFAULT    1 __tiUc
 18295: 00570a80    52 FUNC    GLOBAL DEFAULT    1 __tfUc
 18296: 00747048     8 OBJECT  GLOBAL DEFAULT    1 __tiUs
 18297: 00570a48    52 FUNC    GLOBAL DEFAULT    1 __tfUs
 18298: 00747040     8 OBJECT  GLOBAL DEFAULT    1 __tiUx
 18299: 00570a10    52 FUNC    GLOBAL DEFAULT    1 __tfUx
 18300: 00747038     8 OBJECT  GLOBAL DEFAULT    1 __tiUl
 18301: 005709d8    52 FUNC    GLOBAL DEFAULT    1 __tfUl
 18302: 00747060     0 OBJECT  GLOBAL DEFAULT    1 _GLOBAL_$F$before__C9type_infoRC9type_info

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.