Project64 Debugger 1 2 3 4 5 ... 7 »
Users browsing this thread: 1 Guest(s)

Some games that I would like to hack don't run well in Nemu, so I'm making a new debugger for Project64



​Features
• MIPS debugger
    º Built-in assembler functionality for testing code
• Memory read and write breakpoints
    º Support for cart-to-RAM DMA writes
• Symbol management for subroutines and variables
    º Live view of variable values
• Cart-to-RAM DMA logging
    º RAM-ROM address conversion
    º 4-byte ASCII file signature reporting
• Javascript API
    º CPU read/write/execute event hooking
    º Access to virtual memory
        • JS variable and object binding
    º Access to cartridge memory
    º Access to general purpose and floating point registers
    º Basic socket and server support
    º Console logging & input evaluation
• Static RDRAM allocation
    º Memory base is always 0x10000000 for programs like Cheat Engine

​Download

​How to use
To toggle a PC breakpoint, double click an instruction in the command viewer. To add a memory breakpoint, right click bytes in the memory viewer or press the + button next to the breakpoint list in the command viewer. See apidoc.htm for javascript API documentation.

​Video demos

If you have any suggestions or bug reports feel free to post them!
(This post was last modified: 09-12-2017, 07:15 AM by shygoo.)
My threads are now being maintained here

I just wanted to say, having had the same problem wit Nemu, that this is fantastic! Already it's great and your TODO list looks to make it even better.
Thanks for releasing it Smile

Once nice feature would be highlighting uses of the selected instructions registers, so for example, if the selected instruction is LW T9, 0x0000(A0) you can quickly scan up the list to see where A0 is set, and down the list to see where T9 is used.
(This post was last modified: 26-09-2016, 07:23 AM by jaytheham.)

Awesome idea! It will be included in the next release. https://i.gyazo.com/e7f6beac9735b34d764808d1f233f08c.gif
My threads are now being maintained here

Will it be possible to keep track of the calling stack with this debugging tool?

One thing that might be interesting to see for the purposes of reverse engineering is to be able to define labels for jump and branch instructions, preferrably through some external file. Would be really great is if it also allowed some sort of scripting so that you could define labels for code addressed to virtual spaces. For example, Ocarina of Time's boot animation code is addressed to 80800000, which is then translated to someplace in RAM

Function labeling combined with a callstack would be truly great Big Grin

Thanks so much for this Shygoo! Here's a peak at what I've cooked up with this PJ64 debugger that he's put together:



New snapshot is up - here are some notable new features:
Added javascript api (basic support; just runs whatever is in _api.js & _script.js in a single context on startup)
Made GPR registers in debugger proper 64-bit
Added PI register tab
Memory write breakpoints now catch cart-to-ram DMA transfers
Other features like register usage highlighting, a stack frame viewer, and a symbols manager have also been started - these are far from finished though. Smile

See /apidoc.htm for javascript api documentation
My threads are now being maintained here

Just been using the latest version, great stuff Smile One minor niggle is that the font in the commands window isn't monospace, so if there are lots of As in a register, for example, the last value gets cut off.

Snapshot 3

Memory breakpoints can be managed from the Memory window by right-clicking values
Individual scripts are now stored in "/Scripts"
The API script is now compiled into the binary
Scripts can be run from the Scripts window by double clicking them
Symbols window is somewhat functional

Some additions in this snapshot are half-baked but I figured I'd put something up right now because it's been a while since the last update and having convenient memory breakpoints is important.

Memory breakpoints

[Image: 12cf27ae6b8fab656ee99c036e7b2e5e.png]

Much better now! Big Grin

Scripts

[Image: a857e4cd31b1fb4e1e894dc8978f2ce9.png]

Double-clicking a script name in the list runs a script in its own thread. Yellow means initialising, and green means the event loop is running and events are waiting to fire. If the selected script is in its event loop state, the text input on the bottom can be used to evaluate code within its context (press Enter to run the code, up and down arrows to scroll through input history).

Symbols

[Image: 1d390a907e8c4e06218a10ecbf4eb4ce.png]

Opening the symbols window while a game is running creates a file in "/Save" named "[GAME NAME].sym". Clicking the "+" button adds a new symbol (it doesn't save to the file yet, but manually edited files do work). Double-clicking a symbol with the "code" type opens its address in the commands debugger, and doing the same for any other type opens the memory viewer.

Symbol names with the "code" type show in the command debugger's "Symbol" column and can replace jump targets:



The format for the symbols (.sym) file is plaintext CSV where each line has a hexadecimal address, data type, name, and an optional description in that order. This might be tweaked later to be a superset of Nemu's COD file format for compatibility.

Valid symbol types are: code, data, u8, u16, u32, s8, s16, s64, float, and double.

A symbols file might look something like this:

SUPER MARIO 64.sym Wrote:
802CA8E8,code,exampleProcA
802CA6D0,code,exampleProcB
802CA94C,code,exampleProcC
802CB1C0,code,beh_mario_a,mario behavior function
8033B1AC,float,mario_x,Mario's x position


I'll be sure to address the register textbox overflow and unfinished bits in the next snapshot, hopefully it won't take long Smile
(This post was last modified: 28-03-2017, 09:22 PM by shygoo.)
My threads are now being maintained here

Project64 Debugger 1 2 3 4 5 ... 7 »
Users browsing this thread: 1 Guest(s)