New Actor Variable Editor v2 (WIP)

[Airikita]

Hello everyone,

 

Today I decided to tinker with a new project, for better AI hacking. For now it will be for values, whether it would be float or otherwise. I am running a few tests, and will be updating accordingly. To start with, an entire ROM has to be uploaded to the application in order for the values to be loaded, and it has been tested on 1.0 and Debug so far, and I doubt I will have any issues making this compatible with 1.1 or 1.2 whatsoever.

 

First testing phase:

 

EDIT: I changed the way the list loads, it won't take this long to actually load any more.

 

All actor offsets from the official actor table are loaded, nothing else (if everything works as it should).

 

Unfortunately loading individual actor files is NOT POSSIBLE for the values to be loaded, due to the fact that actor files on their own don't contain relocation information to make the correct changes. Some of you might be aware of this, or not, depending on how experienced you are with AI hacking.

 

This tool will be usable for anyone, not just me.

[Airikita]

Editor now loads faster, and creates a clean list of actor files:

 

 

 

I will move on to making the list generate actor files later, and also will generate values.

[Airikita]

Got the relocations to generate a list:

 

I will have to analyze samples before I begin to generate a complete set of items, since this is only the first step to loading actor values.

 

Error checking is detailed, checking for invalid sizes and offsets, so you can't really spoof this (yet you probably can, I will do another check for size of the actor file vs the size of the relocations, and any array index exceptions).

 

Other anticipations:

Plugging in the altered data file into an emulator to test, removing the need to save over a file every time and load it. I will do this within the application, which will allow choosing an emulator, and a click of the button will send the temporary data to the emulator for testing.

 

It's not perfectly live, but it will be as "live" of an editor as it gets.

 

The obstacles to making it a live editor is not an issue of reading the RAM, but rather an issue of converting the values to ROM later. It's possible to load the data from emulator RAM, but I will have to look into it later as an option.

 

You could, in theory, create a ROM file from the RAM data. You won't get a live edit, but you can likely reload the map you're testing in by moving around Link. That will be reviewed later in the project as the main focus is the ROM file for now.

[Conker]

Great stuff.

[Airikita]

Thanks, and I'm on a roll tonight...

 

I tried to look up how to get the process PID, and every Java site I went to was like "Nuh, you can't do that!"...

 

Well, behold:

 

I got it from Windows' task manager, but now I don't know if I can get it to work for Linux. I could try to find the path for Linux's process list, but maybe not...

 

Also, Nemu64 is being a little butthole from my app trying to execute it. I don't know why, but Nemu throws pissy errors when you try to open it from another application... which is weird.

 

The PID always changes, so this is just an identifier for Windows' runtime to eventually find the RAM source. Might need to tinker with it more.

 

I'm a bit stumped on one of the relocators though... does anyone know what the C2XXXXXX operation is for? It seems to be a duplicate of another relocator.

[Jason777]

Nemu might have relative pathing issues.

[Mallos31]

Thanks, and I'm on a roll tonight...

 

I tried to look up how to get the process PID, and every Java site I went to was like "Nuh, you can't do that!"...

 

Well, behold:

 

I got it from Windows' task manager, but now I don't know if I can get it to work for Linux. I could try to find the path for Linux's process list, but maybe not...

 

Also, Nemu64 is being a little butthole from my app trying to execute it. I don't know why, but Nemu throws pissy errors when you try to open it from another application... which is weird.

 

The PID always changes, so this is just an identifier for Windows' runtime to eventually find the RAM source. Might need to tinker with it more.

 

I'm a bit stumped on one of the relocators though... does anyone know what the C2XXXXXX operation is for? It seems to be a duplicate of another relocator.

Bullll. Java can do anything! Have these people SEEN Minecraft and Runescape? That's some pretty crazy Java stuff!

[haddockd]

Well, I dont know about a C2 operation but I do have a small snippet of code that might "inspire" you. Mind you it is in C#. This code finds all processes with the Adobe or Acrobat process names and kills them. The processID doesn't matter in this example.

 

                        foreach (Process clsProcess in Process.GetProcesses())

                        {

 

                            if (clsProcess.ProcessName.StartsWith("AcroRd32"))

                                clsProcess.Kill();

                            if (clsProcess.ProcessName.StartsWith("AcroRd64"))

                                clsProcess.Kill();

                            if (clsProcess.ProcessName.StartsWith("Acrobat"))

                                clsProcess.Kill();

                        }//end foreach

 

I might be missing the point though. I am very tired.

[Airikita]

 

Well, I dont know about a C2 operation but I do have a small snippet of code that might "inspire" you. Mind you it is in C#. This code finds all processes with the Adobe or Acrobat process names and kills them. The processID doesn't matter in this example.

 

                        foreach (Process clsProcess in Process.GetProcesses())

                        {

 

                            if (clsProcess.ProcessName.StartsWith("AcroRd32"))

                                clsProcess.Kill();

                            if (clsProcess.ProcessName.StartsWith("AcroRd64"))

                                clsProcess.Kill();

                            if (clsProcess.ProcessName.StartsWith("Acrobat"))

                                clsProcess.Kill();

                        }//end foreach

 

I might be missing the point though. I am very tired.

 

It's interesting, yeah, but I just found something to work with something in particular. Right now it appears to be a Windows-only tool, I don't know if I'll work on it to work for Linux yet as I have to work out the kinks.

 

I picked up a book titled "Windows XP Secrets" from the library, it has some info on Windows' console and .msc files, so I will hopefully dig up something with that.

[Airikita]

EDIT:

Reviewing C2 and 82 commands, they seem to relocate display lists within the code... so they're a bit irrelevant, which is good... I wasn't going to just fix them without first knowing what they were. It's not like I need to associate the zobj file with the actor AI file (although it's possible I could do that later, which will require other options).

 

I could go full-on actor/object editor if I get the right fixings. Would be better if I could hook the emulator process, but I'll have to focus on the file for now. The Pid is obtained, but the JAR files to read from process memory are all mixed up, and there's little documentation on them. I might have to use C# to get the RAM data of a ROM, which I'll have to research later as I never fully coded in C before.

 

Also, it could be possible to read the RAM for the OoT ROM, but I don't know a way yet... not without digging at the process, which is turning out to be too OS-specific if I tinker at it. Might not end up with what I need either.

 

I found a way to do it with Linux, but I'm not going to be shitty and just make it do the operation for Linux. Besides, testing in Linux is.... blargh!!! I'm too used to Windows like that.

 

Not saying I won't make it available for Linux, but one without the other defeats the purpose of the feature for me.

 

And chances are it may not even work.

 

EDIT2:

UPDATE:

And... with some spare time, here's a generated list of static values from a sample actor:

Same can be done for any actor. It also seems there are more relocation values shoved in there, so I might have to look into them. They could point to functions, so it's likely I may not change those, but rather filter them out (but still keep them).

 

It's likely other relocators are filtering those out, possibly the 82XXXXXX or C2XXXXXX operations I found earlier

[Airikita]

Just updating...

 

Unfortunately due to my schedule, and circumstances with Java not cooperating with what I want it to do, this might be on hiatus for a while. That is, if anyone is still interested, I will work on it harder. But due to current situations, I may not have time to complete this properly.

 

I can still make a release with it just being a ROM editor and not run the emulator for now.

 

Java's error handling is shitty to Nemu, which is shitty when Nemu is still a great tool to use, and would be a boon if Java would stop being an anus over it.

 

Let me know your thoughts, I need to know if anyone is interested in this or not.

 

It could be fixable, but the Java community are not being helpful either, but I could try a different source.

 

========================================================================================================================

 

EDIT (UPDATE):

I fiddled around with it, and came to something close:

 

 

 

It's easier to run it in mupen and a TEST rom will be loaded into mupen64plus, not the actual ROM you uploaded, so you can test your changes before saving your ROM. It creates a dummy file in order to accomplish this, which will only last as long as your session in the app.

 

So far this is what I got, I don't know if I can plug in extra commands to mupen64plus as Java is limited in accessing processes appropriately in Windows.

 

========================================================================================================================

 

EDIT 2 (UPDATE):

I believe I have figured out a way to make this tool a LIVE EDITOR!!! I'm only guessing for now, testing phase will have to be next in order to be sure. However the app is still incomplete, the results of the test are different from just opening the file in mupen64plus.

 

I have a good feeling about it though.

[Airikita]

So this is the "current" setup, including the ability to load a "dummy" ROM file to mupen64plus:

 

This will not affect the ROM you uploaded for testing, it will create a false/fake file, which basically tricks mupen64plus into loading any altered data for testing.

 

This test wasn't a great example, but perhaps later tests will prove positive. I'm hoping the Live Editing feature will work properly as I have had some results from a previous test that suggests it should work.

 

EDIT:

Live editing doesn't seem to be working, it seems as though I'm limited with Java for writing data... I will try other methods however

[Antidote]

Getting a process on linux is actually pretty easy:

 

[antidote@the-key-bearer ~]$ ps -A | grep 010

 4647 ?        00:01:07 010editor

 

The first entry is the PID, and it follows this format:

 

PID -        User      - Execution time - Process Name

4647  ?(antidote)        1hr 7m               010editor

 

Also Looking good Airikita

[Airikita]

 

Getting a process on linux is actually pretty easy:

 

[antidote@the-key-bearer ~]$ ps -A | grep 010

 4647 ?        00:01:07 010editor

 

The first entry is the PID, and it follows this format:

 

PID -        User      - Execution time - Process Name

4647  ?(antidote)        1hr 7m               010editor

 

Also Looking good Airikita

 

Yeah, I read up about getting it on Linux... anyways, I have the tool run a dummy ROM in mupen64plus...

 

I was hoping for a Live Editor, but I don't know how to get Java to work with the Process object like that. I tried getOutputStream.write, but eh... I wasn't 100% on it working.

[haddockd]

I believe java was designed that way. There used to be small ways to do it but they were depreciated I believe. You can always call a C or C++ code piece to do what you want but I do not think it is going to be easily doable in java (yet another reason java sucks )

 

http://www.javaworld.com/javaworld/javatips/jw-javatip17.html

[Airikita]

I believe java was designed that way. There used to be small ways to do it but they were depreciated I believe. You can always call a C or C++ code piece to do what you want but I do not think it is going to be easily doable in java (yet another reason java sucks )

 

http://www.javaworld.com/javaworld/javatips/jw-javatip17.html

Yeah no worries, tis my next move~

[Airikita]

Hey guys, I haven't got around to any changes lately (really behind in school work, a lot of work...), so I might release a prototype for now... I could add a save feature, and just slap it on my MediaFire for access. I'm also still waiting for someone to test my mod, so it's not like I'm out yet, just everything is held back.

 

So, is anyone interested in a prototype? I could keep working on it, but I'll have to review things again to be sure I'm getting the right functions, etc... from actor data files.

 

It can get messy, since there are functions within the code that I will have to convert, and think about how to use that. I would have to read the data like an interpreter would.