Register - Login
Views: 99791528
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-03-22 04:36:40 AM
Jul - General Game/ROM Hacking - Galatea - A Swiss Army knife for hacking MIPS R3000 based software New poll - New thread - New reply
Next newer thread | Next older thread
sirtophat
Random nobody
Level: 3


Posts: 1/1
EXP: 64
For next: 64

Since: 12-10-10


Since last post: 11.4 years
Last activity: 11.3 years
Posted on 12-10-10 09:22:39 PM (last edited by sirtophat at 12-10-10 06:29 PM) Link | Quote
So I posted this:

http://64.vg/dr/node/88


Dec 10 18:09:53 wareya> okay so sth go post "My friend said 'hey can you tell this to these guys "The author of this program is a cool dude, and he said to me 'can you post this on some
Dec 10 18:09:56 wareya> reputable hacking forums' and I was like 'what do I say' and then someone else was like 'the
Dec 10 18:09:59 wareya> author of this tool wanted me to post it here'"'"

then wareya was mad so I'm posting what he wants me to:

My friend said 'hey can you tell this to these guys "The author of this program is a cool dude, and he said to me 'can you post this on some reputable hacking forums' and I was like 'what do I say' and then someone else was like 'the author of this tool wanted me to post it here'"'
Joe
Common spammer
🍬
Level: 111


Posts: 1673/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-11-10 08:27:03 AM Link | Quote
This looks interesting.

It uses GCC, the compiler that produces such genius as: 
0xA40010F4  ADDIU   $t5, $t5, 0x0000
And: 
0xA40010D8  LUI     $t5, 0xA410

0xA40010DC  LW      $t7, 0x0C($t5)

0xA40010E0  ADDIU   $t5, $t5, 0x000C

0xA40010E4  ANDI    $t7, $t7, 0x0020

0xA40010E8  BNEL    $t7, $r0, 0xA40010DC

0xA40010EC  LUI     $t5, 0xA410
Now, GCC isn't all bad. It did optimize a lot of register access for pipelined execution.

The disassembler (the only part I'm interested in) crashed when I scrolled too far down. I ought to file a bug report.

Also, the N64 is MIPS R4000 based, not R3000.

____________________
Marshall
Random nobody
Level: 7


Posts: 1/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-11-10 10:52:48 AM Link | Quote
Originally posted by Joe
This looks interesting.

It uses GCC, the compiler that produces such genius as: 
0xA40010F4  ADDIU   $t5, $t5, 0x0000
And: 
0xA40010D8  LUI     $t5, 0xA410

0xA40010DC  LW      $t7, 0x0C($t5)

0xA40010E0  ADDIU   $t5, $t5, 0x000C

0xA40010E4  ANDI    $t7, $t7, 0x0020

0xA40010E8  BNEL    $t7, $r0, 0xA40010DC

0xA40010EC  LUI     $t5, 0xA410
Now, GCC isn't all bad. It did optimize a lot of register access for pipelined execution.

Where in the world is that code from? Late '90s? If that's the case, then I am not at all surprised. Look at Mario 64's disassembly and you'll see that the MIPS code generation for GCC back then was atrocious, but that is no longer the case. By the way, always use ".set noreorder" in your source when you're writing assembly for the GNU assembler; but you probably already knew that.

Another thing that may put you off is if you see something like this (in disassembled output): 
lui         $t7,0x8040

addiu       $t7,$t7,0x0000

There is no way around this. GCC doesn't know that the address it's going to be referring to in the linked output only needs a 'lui' instruction. It always generates a lui/ori pair and a corresponding pair of HI16 and LO16 relocations: 
lui         $t7,%hi(whatever)

addiu       $t7,$t7,%lo(whatever)


All this GCC bickering is irrelevant anyway, since I'm assuming most assembly hackers use, well, assembly.

Originally posted by Joe

The disassembler (the only part I'm interested in) crashed when I scrolled too far down. I ought to file a bug report.

Could you give me a little information about the file?

Originally posted by Joe
Also, the N64 is MIPS R4000 based, not R3000.

Yes, I am aware, but ORIGINALLY I set out to integrate a sort of assembly tracer for MIPS binaries conforming to the o32 ABI (which is for the MIPS R3000 processor), and as you may know, all N64 games use this ABI.

Thank you kindly for your input.
Joe
Common spammer
🍬
Level: 111


Posts: 1674/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-11-10 09:45:29 PM Link | Quote
Originally posted by Marshall
Originally posted by Joe
...
Could you give me a little information about the file?
It's the N64 boot code located at 0xBFC00000. I have it in both NTSC and PAL, in case you'd like me to send you a copy.

Originally posted by Marshall
Where in the world is that code from?
My hand-disassembly of said boot code. Notice how it executes from RSP IMEM.

____________________
Marshall
Random nobody
Level: 7


Posts: 2/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-11-10 11:41:41 PM Link | Quote
Originally posted by Joe
Originally posted by Marshall
Originally posted by Joe
...
Could you give me a little information about the file?
It's the N64 boot code located at 0xBFC00000. I have it in both NTSC and PAL, in case you'd like me to send you a copy.

I've posted an update to the program, so if it doesn't work now, you may as well send me the file. You probably know my email address from the crash screen :-)

Originally posted by Joe
Originally posted by Marshall
Where in the world is that code from?
My hand-disassembly of said boot code. Notice how it executes from RSP IMEM.

Figured it was something like that. One trick of writing C is knowing the compiler and what it has trouble with on your native architecture.
Hectamatatortron
Member
Level: 35


Posts: 217/232
EXP: 258214
For next: 21722

Since: 09-19-07


Since last post: 7.2 years
Last activity: 5.3 years
Posted on 12-12-10 03:32:50 AM (last edited by Hectamatatortron at 12-12-10 12:35 AM) Link | Quote
Wait, upon reading that again, could you please clarify...

"hand" disassembly?

I have hand assembled stuff before. My first programs were written in straight binary.

Reversing them from binary manually is something even more insane that I cannot begin to comprehend the magnitude of the lunacy of.

____________________
Joe
Common spammer
🍬
Level: 111


Posts: 1676/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 03:59:33 AM Link | Quote
Originally posted by Marshall
I've posted an update to the program, so if it doesn't work now, you may as well send me the file. You probably know my email address from the crash screen :-)
Whatever you did fixed it. Thanks!

So, is there any way to get the disassembler to disassemble more than a screen's worth of code? Right now I can't get it to disassemble the entire block of code that executes before the jump to IMEM.

Trying to reassemble it puked up some errors: 
4: Error: illegal operands `mtc0 $9,$c12'

7: Error: illegal operands `mtc0 $9,$c16'

14: Warning: Used $at without ".set noat"

15: Warning: Used $at without ".set noat"
Of course, reassembling this code is pretty much pointless, so if it's supposed to be unhappy with reassembling the boot code then everything's okay.

____________________
Marshall
Random nobody
Level: 7


Posts: 3/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-12-10 02:54:39 PM (last edited by Marshall at 12-12-10 11:55 AM) Link | Quote
Originally posted by Joe
So, is there any way to get the disassembler to disassemble more than a screen's worth of code? Right now I can't get it to disassemble the entire block of code that executes before the jump to IMEM.

New version up where I've added an assembly export menu akin to Nemu's - just press the green-arrow-on-white-paper icon in the disassembler. You have to write in the address span manually, though, since I don't really know how to make the selection in the list view span more than what it draws - since as you may tell, the list view is not loaded up with the entire content of the file at one point. It's streamed sorta.

Originally posted by Joe

Trying to reassemble it puked up some errors: 
4: Error: illegal operands `mtc0 $9,$c12'

7: Error: illegal operands `mtc0 $9,$c16'

14: Warning: Used $at without ".set noat"

15: Warning: Used $at without ".set noat"
Of course, reassembling this code is pretty much pointless, so if it's supposed to be unhappy with reassembling the boot code then everything's okay.

Heheh, well it shouldn't be unhappy with it. Check out the "mips.h" header file at (if I recall correctly) gcc/mips64/include in the distribution. There are some defined COP0 register names from NetBSD in there. The GNU assembler usually just refers to the registers with their number (e.g, $0) - COP0 included - hence the need for a supplementary header.
Joe
Common spammer
🍬
Level: 111


Posts: 1679/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 06:45:10 PM Link | Quote
It looks like that header uses names like C0_SR and C0_CONFIG while your disassembler uses names like $c12 and $c16. Fixing that causes a compiler error: 
56: Internal error!

Assertion failure in md_apply_fix3 at .././gas/config/tc-mips.c line 10939.

Please report this bug.

Trying to dump the entire file says it processed at infinity instructions per second. Trying to dump only the instructions from 0xBFC00000 to 0xBFC000D0 causes it to divide by zero and output an empty file.

____________________
Marshall
Random nobody
Level: 7


Posts: 4/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-12-10 06:55:42 PM Link | Quote
Originally posted by Joe
It looks like that header uses names like C0_SR and C0_CONFIG while your disassembler uses names like $c12 and $c16.

Ah, my bad. It's been a while since I've done any work with the memory coprocessor. I'll add the proper names as they're defined in mips.h for the next update. :-)

Originally posted by Joe

Fixing that causes a compiler error: 
56: Internal error!

Assertion failure in md_apply_fix3 at .././gas/config/tc-mips.c line 10939.

Please report this bug.

I think this is due to a branch instruction that refers to an absolute address rather than a label. Try adding a label instead.

Originally posted by Joe

Trying to dump the entire file says it processed at infinity instructions per second. Trying to dump only the instructions from 0xBFC00000 to 0xBFC000D0 causes it to divide by zero and output an empty file.

I don't think it's the address throwing it off, as I just tried it by loading a RAM dump at 0xBFC00000 and it output fine. Are you using the latest version? Would it be possible for you to send me the file via e-mail?
Joe
Common spammer
🍬
Level: 111


Posts: 1681/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 07:12:03 PM Link | Quote
Originally posted by Marshall
I think this is due to a branch instruction that refers to an absolute address rather than a label. Try adding a label instead.
Hey, you're right, that fixed it.
Originally posted by Marshall
I don't think it's the address throwing it off, as I just tried it by loading a RAM dump at 0xBFC00000 and it output fine. Are you using the latest version? Would it be possible for you to send me the file via e-mail?
Sure, it'll just be a moment.

____________________
Marshall
Random nobody
Level: 7


Posts: 5/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-12-10 07:21:45 PM (last edited by Marshall at 12-12-10 04:22 PM) Link | Quote
Originally posted by Joe
Originally posted by Marshall
I don't think it's the address throwing it off, as I just tried it by loading a RAM dump at 0xBFC00000 and it output fine. Are you using the latest version? Would it be possible for you to send me the file via e-mail?
Sure, it'll just be a moment.

Got it! Thanks.

Tried it out myself, didn't experience any problems (except for the Infinity/sec thing). Output is here. I've uploaded a new update of the program with the COP0 register names issue fixed. Try using that one and see if you still encounter problems.
Joe
Common spammer
🍬
Level: 111


Posts: 1682/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 07:45:40 PM Link | Quote
Originally posted by Marshall
Tried it out myself, didn't experience any problems (except for the Infinity/sec thing).
Did you change the end address to 0xbfc000d0? When I do that, it halts and informs me it tried to divide by zero.

____________________
Marshall
Random nobody
Level: 7


Posts: 6/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-12-10 08:01:34 PM Link | Quote
Originally posted by Joe
Originally posted by Marshall
Tried it out myself, didn't experience any problems (except for the Infinity/sec thing).
Did you change the end address to 0xbfc000d0? When I do that, it halts and informs me it tried to divide by zero.

Tried that just now. No errors. Does it output a stack trace?
Joe
Common spammer
🍬
Level: 111


Posts: 1683/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 08:52:31 PM (last edited by Joe at 12-12-10 05:53 PM) Link | Quote
It doesn't crash, so there's no stack trace. Try changing the end address to 0xbfc00004, since it seems more likely to error out with smaller disassemblies.

Originally posted by Hectamatatortron
Wait, upon reading that again, could you please clarify...

"hand" disassembly?
Taking a binary file and making opcodes out of it. Yes, it is insane and tedious. I was bored and I needed a timewaster. (And sorry I missed your post earlier.)

____________________
Marshall
Random nobody
Level: 7


Posts: 7/7
EXP: 1194
For next: 254

Since: 12-11-10


Since last post: 11.4 years
Last activity: 10.3 years
Posted on 12-12-10 09:32:20 PM Link | Quote
Originally posted by Joe
It doesn't crash, so there's no stack trace. Try changing the end address to 0xbfc00004, since it seems more likely to error out with smaller disassemblies.

Ah, now I see it! Can't be bothered to make an entirely new update right now, so just replace the "Galatea.dll" with this. Thanks for helping me track this down

____________________
Joe
Common spammer
🍬
Level: 111


Posts: 1685/3392
EXP: 14501023
For next: 367337

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 6 hours
Posted on 12-12-10 11:42:06 PM Link | Quote
You're welcome.

If I find any more problems, I'll let you know.

____________________
Next newer thread | Next older thread
Jul - General Game/ROM Hacking - Galatea - A Swiss Army knife for hacking MIPS R3000 based software New poll - New thread - New reply


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

31 database queries, 13 query cache hits.
Query execution time: 0.088034 seconds
Script execution time: 0.025781 seconds
Total render time: 0.113815 seconds