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]?
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.
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.
[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:/>/>/>
[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?
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...
From what I can tell, it does follow the standards for the ELF format - so I guess that is excellent news. :specialed:
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)
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.
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.
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.
According to these tools, I was wrong and that's not a symbol table? Code (Text): 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: Code (Text): 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.
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.
(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.
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.
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.
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.