Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,433,507
 Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 04-18-24 10:34 PM
Guest: Register | Login

0 users currently in ROM Hacking Related Releases | 1 guest | 1 bot

Main - ROM Hacking Related Releases - Tool source code dumpage: a SM64 disassembler New thread | New reply


Cellar Dweller
Posted on 11-13-08 09:43 PM Link | Quote | ID: 94225


Snifit
Level: 39

Posts: 137/287
EXP: 384956
Next: 19815

Since: 02-19-07
From: Arkansas

Last post: 4044 days
Last view: 3212 days 		Due to a possible prolonged loss of internet access starting in the next few days, I'm hurriedly posting the source code for a reverse engineering tool that I had been working on. This is not a tool that I would normally consider release quality, so I'm not posting it in the releases forum. The code is a ugly and slow, but may be useful for certain SM64 hackers who can code in C.

It takes a SM64 US ROM in ABCD order and an optional symbol list as arguments, and spits out a bunch of stuff on stdout. I suggest using the less pager or redirecting to a file.

A symbol list based on Nagra's is posted here too.

n64_dis_0.01.tar.gz
syms.txt

KP9000
Posted on 11-14-08 12:40 AM Link | Quote | ID: 94235


Boomboom

Level: 90

Posts: 569/1975
EXP: 6949187
Next: 239422

Since: 02-19-07

Last post: 3572 days
Last view: 3196 days


While you may not feel that it is worthy to be called a release, it is still indeed a release. Therefore, I've moved it to the Releases forum. Users still download at their own judgment.

People here are resourceful (most of the time) and can deal with this "quality" of a release. They're usually more than happy to get releases such as this; the more the N64 hacking scene gets the better off they are.

____________________

messiaen
Posted on 11-15-08 02:57 PM Link | Quote | ID: 94354


Cheep-cheep
Level: 32

Posts: 77/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		Wow, this will certainly be 'ultra' useful, even for people disassembling other N64 games. The Makefile in the package was null, but this worked for me: 


CC = gcc

CFLAGS = -Wall -g
LFLAGS = -g

COMMON_OBJS = xref.o sym.o region.o jtabs.o dumpmips.o disasm.o

CLI_OBJS = main.o
CLI_BIN = main

$(CLI_BIN): $(COMMON_OBJS) $(CLI_OBJS)
	$(CC) $(LFLAGS) -o $(CLI_BIN) $(COMMON_OBJS) $(CLI_OBJS)
clean:
	rm -f $(COMMON_OBJS) $(CLI_BIN) $(CLI_OBJS)

depend:
	gcc -MM *.c* > Makefile.deps

include Makefile.deps


I have not checked yet how the syms.txt is used for the output, but are the function names supposed to be printed (I ask because it didn't happen to me) ? I'm compiling also a list of some useful functions shared by many objects, things such as CreateStar(float x, float y, float x), ScaleObject and this kind of stuf .

Cellar Dweller
Posted on 11-15-08 09:41 PM Link | Quote | ID: 94368


Snifit
Level: 39

Posts: 139/287
EXP: 384956
Next: 19815

Since: 02-19-07
From: Arkansas

Last post: 4044 days
Last view: 3212 days 		Did you supply the symbol file as the second command line argument? If you did, it should print the names of functions at the start of the function and at any JAL instruction.

If you get the symbol file working, feel free to post your edited version. To keep the file neat, I have been adding the entries in order by address. If you want to add another location to start disassembling from (you may want to do this if you find that functions that you are interested in are being missed), have a look at main.c. Note that jump tables and functions are in separate starting point lists.

messiaen
Posted on 11-16-08 11:18 PM Link | Quote | ID: 94430


Cheep-cheep
Level: 32

Posts: 78/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		I supplied it as the second line argument, but I always get on this infinite loop:

syms.c: 53 

	while (!feof(s)) {
		char *name;
		uint32_t addr;
		
		if (fscanf(s, "0x%x,%as\n", &addr, &name) == 2) {
			printf("0x%08x is %s\n", addr, name);
			add_sym(name, addr, 0);
			free(name);
		} else {
			printf("%d\n", ftell(s));     /*I get trapped on this */
		}


Also, is there something wrong with this? Even if I supply a valid ROM as the first argument, it doesn't pass this conditional:

main.c: 74 

    if (!((s = fopen(argv[1], "r")) && (buf = malloc(8*1024*1024)) && fread(buf, 8*1024*1024, 1, s))) {
        printf("Error opening file.\n"); 
        return 1;
    }


It only worked for me when I removed it.

Cellar Dweller
Posted on 11-17-08 12:55 AM Link | Quote | ID: 94433


Snifit
Level: 39

Posts: 140/287
EXP: 384956
Next: 19815

Since: 02-19-07
From: Arkansas

Last post: 4044 days
Last view: 3212 days 		On the main.c one, try changing the mode from "r" to "rb".

As for the syms.c loop, I'm thinking it might be an OS dependent issue such as line endings. What OS and compiler are you using? What is printed before and while the loop is stuck?


messiaen
Posted on 11-17-08 03:07 AM (rev. 2 of 11-17-08 03:09 AM) Link | Quote | ID: 94437


Cheep-cheep
Level: 32

Posts: 79/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		I'm using Mingw/GCC 3.4.2 on Windows XP (with Bloodshed's Dev-cpp IDE).

The problem apparently isn't on the newlines but rather on the "comma", as ftell(s) returns "11" (0x0b) while on that infinite loop, which happens to be the position of the first comma in the syms.txt file. 

if (fscanf(s, "0x%x,%as\n", &addr, &name) == 2)

Out of curiosity, I searched some reference and couldn't find what does the %as (especifically, the character 'a' before %s) means? I also tried this to see if looking for any character (using %c) instead of the comma would work: 

if (fscanf(s, "0x%x%c%as\n", &addr, &wasted_ch, &name) == 2)

But the output was: "0x80173fd4 is (null) [crashes the program]".

Sorry if these are too basic questions/problems .

Cellar Dweller
Posted on 11-17-08 04:47 AM (rev. 2 of 11-17-08 04:54 AM) Link | Quote | ID: 94440


Snifit
Level: 39

Posts: 141/287
EXP: 384956
Next: 19815

Since: 02-19-07
From: Arkansas

Last post: 4044 days
Last view: 3212 days 		That explains it. I had forgotten that the "a" modifier for the string conversion specifier, "%s", is a non-standard GNU extension. The binaries that are produced with Dev-cpp are linked with Microsoft's C runtime, which does not support the extension.

This is a really ugly hack, but you could try changing "char *name" to "char name[1024]", removing the ampersand from the name variable on the fscanf line, removing the non-standard "a" modifier, and removing the "free(name);" line. Note that this will crash the program if any of the names in the symbol file are too long to fit in the buffer, and will create a security vulnerability that can be exploited by a maliciously crafted symbol file. If I get around to making another release, I intend to fix this a better way.

EDIT: You could add a length modifier to prevent a security vulnerability, but it would still break if a too long name is in the symbol file.

messiaen
Posted on 11-18-08 01:43 PM Link | Quote | ID: 94569


Cheep-cheep
Level: 32

Posts: 80/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		With this 'hack', the syms.txt file worked, I'll keep in mind the possible problems.

If you don't mind, could you explain a bit the difference between add_region and schedule_disasm functions? With my limited C kwnoledge, I got a bit lost on all that linked lists .

main.c : 85 


    add_region(0x80246000, 0x80340fff - 0x80246000, buf + 0x001000);
    add_region(0x80378800, 0x8038bc90 - 0x80378800, buf + 0x0f5580);
    
    schedule_disasm(0x80248af0, 0x80248af0);
    schedule_disasm(0x803839cc, 0x803839cc);
    chedule_disasm(0x802469b8, 0x802469b8);


From this snippet I can see that two of the schedule_disasm functions points to thread entry-points, but why is the 0x803839cc object solidity-related function there?

Also, is the add_region supposed to disassemble the entire range between start PC + size? While looking at the output, I missed a few functions that should be in the checksum area range, so I guess the disassembly is a bit more selective?

I'm working on a huge syms.txt file, including also the functions called by behavior scripts, when it's done I'll upload it to the board uploader.

Cellar Dweller
Posted on 11-18-08 07:01 PM Link | Quote | ID: 94587


Snifit
Level: 39

Posts: 143/287
EXP: 384956
Next: 19815

Since: 02-19-07
From: Arkansas

Last post: 4044 days
Last view: 3212 days 		The add_region function maps parts of the ROM to the simulated address space of the N64 CPU. One of the add_region calls is for the checksum area ASM and the other is for the script interpreter area ASM. I have not added the Mario head intro code simply because I have not had much interest in reverse engineering it.

The schedule_disasm calls specifies starting points for disassembly. The disassembler follows function calls and jumps to find more code to disassemble. Jump tables are missed by this method, so there are also lists of jump tables in main.c.

If you want the functions called from scripts to be disassembled by this program, you will need to add a schedule_disasm call for each one. I think that is how the solidity related function got added.

messiaen
Posted on 11-19-08 07:56 PM Link | Quote | ID: 94649


Cheep-cheep
Level: 32

Posts: 82/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		Thanks, now things are much clearer!

Now the only thing missing for this to become a dream tool would be to make it read a user-defined file with the object struct (or other user-defined struct) and map it into the dissassembly, to produce an output like this: 


802EFCD4: LUI T6, 0x8036
802EFCD8: LW T6, 0x1160 (T6)
802EFCDC: LW A0, 0x0144 (T6)
    ; xref to *80361160 -> 0x144 (arg1 from 0x24 level cmd).


Thanks again for releasing this tool, it'll certainly be very useful.

messiaen
Posted on 12-08-08 02:33 PM Link | Quote | ID: 96149


Cheep-cheep
Level: 32

Posts: 97/193
EXP: 204319
Next: 2123

Since: 05-26-08
From: Porto Alegre, Brazil

Last post: 4435 days
Last view: 4763 days 		A few functions/addresses for syms.txt. Some of them come from your notes (and there's a few more to include), and one of two are renamed from Nagra's original list. 


0x80222618,master_music_controller
0x802485e4,title_screen_sounds
0x8024a9cc,collision_cmd_32
0x80250724,collicion_cmd_33(princess_slide_start)
0x80250778,collision_cmd_34(princess_slide_finish)
0x802505c8,collision_cmd_0a(death_at_bottom)
0x8025065c,collision_cmd_01(lava)
0x80253720,display_debug(ang/spd/sta)
0x802771bc,mario_blink_related
0x80277f50,segmented_to_virtual
0x8029000c,camera_related(stop_camera?)
0x8029a2f8,camera_related2?
0x8029db48,obj_blink
0x8029edcc,spawn_obj(obj*,model_id,behavior)
0x8029f430,scale_obj
0x802a0568,clear_obj->0x74
0x802a3e30,process_obj_action_from_jump_table
0x802a4be4,create_message_box
0x802a50fc,twhomp_shake_screen
0x802c9f04,init_object_behavior
0x802ca190,play_sound
0x802f2b88,spawn_star(float_x,float_y,float_z)
0x8031c050,readTrackByte
0x8031c080,readTrackVarLen
0x8032ddc4,geo_layout_ptrs_table
0x8032ddf8,current_level_ID
0x8033b400,segment_table_ptrs
0x80361160,current_obj_ptr
0x80378800,camera_related?
0x803833b8,toplevel_solidity_command_processing
0x803839cc,process_obj_solidity
0x8038b8ac,current_area_for_level_loading

Main - ROM Hacking Related Releases - Tool source code dumpage: a SM64 disassembler New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.025 seconds. (326KB of memory used)
MySQL - queries: 92, rows: 115/115, time: 0.017 seconds.