Views: 874,524,306
24 users online:  1UPdudes, Arobam, callmeCMDR, crowhander, Diba9Br,  E-man38, Enan63, Evil_Abed, Final Theory, FlashHacks, h.carrell, KatMakes, Linatic, MarioriaM, OrangeBronzeDaisy, qantuum, Raymondsze, Recipate, RPG Hacker, Rykon-V73, supermargot,  Telinc1, UTF, WhiteYoshiEgg - Guests: 92 - Bots: 176 Users: 48,729 (2,432 active)
Latest: SeanyBoi5
Winter C3 2021 Content Spotlight
HaruMKT's "Hybrid Front Project Teaser"!
Not logged in.
Posts by UGotBalls
UGotBalls' Profile - Posts by UGotBalls
Pages: « 1 2 »
Originally posted by pieordie1
TT64 works horribly on windows 8 on my computer(slow, crashes occasionally, won't open Castle Grounds after level imported into it), and level importer messes up and does not show my preview. Maybe I just exported wrong because I've been using sketchup 2013. Anyways, how do the scrolling textures work. I could not understand how to do it.

What idiot would need Windows 8? It's the biggest crap, that ever existed. Even "BIG" business magazines are saying, that Windows 8 was a total fail.

Your layout has been removed.
Both, tarek701 and damihack, failed to realize, that the actual link to MinGW is NOWHERE! And still, there are instructions for it.
If you make a tutorial, you should first look over it, before you post it. If I'm wrong, correct me. But both links lead to n64tree-win32. So, fix your stuff please before posting anything.

Your layout has been removed.
Originally posted by Megaman511again
Hello everyone! My name is Megaman511again, and I love hacking Super Mario 64, and there is usually stuff I would love seeing be on that game, just for fun.

1. One idea I have is someone ripping the models of stages from the DS version of SM64 and putting it on the original 64 version.

2. I think someone's already doing this but I would also love to see someone port almost all stages from Super Mario Sunshine into Super Mario 64.

3. It would be cool to see more character hacks, we already have Kirby, it would be nice to see Sonic, Link, Samus, Wario, Waluigi, or other characters in Super Mario 64.

4. I don't know if this may be impossible currently, but custom cutscenes could be cool.

Any other ideas would be awesome. Those are ideas I think can happen, I sadly don't have the knowledge of being able to do this myself, but hey, I have dreams, haha.

1. Why don't you do it? Isn't really that hard.
2. Mhhh... Okay. Well, Super Mario Sunshine in SM64 isn't something I would like to see. (Yes, it totally ruins the classic for me, sorry but true) More likely, I would like to see a recreation of FLUDD in SM64 through ASM hacking.
3. Oh yeah, cause it's so easy to get sonic, link and other game characters easily in game. Imagine how long it takes. Importing the model wouldn't be a problem, but fixing the problems, that occur after importing model, is the true problem.
4. "Impossible" is such a funny word. Of course, it's possible. However, the methods on how to do it aren't available yet. Anything needs development, this goes also for hacking and every other crap in our unforgiven lifes.

Your layout has been removed.
Originally posted by mario and luigi

when i try to open my rom to expand in m64romextender, it gives me this message. what does this mean?

edit: is there a way to convert ppf files into xdelta format? i find xdelta much more easier which does not require expansion.

and when i do patch the rom WITHOUT expanding, my emulator crashes and says "in a permanent loop that cannot be exited. emulation will now stop. verify rom and rom settings" and sometimes it also says "unknown cic chip".

Maybe you try something and actually "follow" the instructions given in this message? If it doesn't work, try to run it as administrator, as the message clearly says that your account has insufficient permissions.

The looping error happens, because the checksum isn't fixed aka recalculated. It's obvious, that without expanding, the patch's not gonna work well on the ROM.

Your layout has been removed.
Interessting work, Kazeshin. There are not that much amount of people, who can actually do this. Not only that the most here are mentally disturbed, but also because they like to be lazy as shit and stalk VL-Tone to complete TT64, a great person, who actually haves a life. (I never expected, that people would surprise this. Surpriseception)

I've been working with MIPS R4300i Assembly for a quite while, I also got how addresses, values are being counted and loaded. I admit, it quite confused me at the beginning, but later it was really simple.

As I see, you're the only one here with enough knowledge about MIPS. Is it possible, if you can make a MIPS Assembly tutorial? I heard someone made one, but was quite bad, so I'm asking if you're able to do it.

Your layout has been removed.
Originally posted by Shog
If I understand it correctly in the tutorial, this file is for seeing how big Mario, etc. is.

But for SketchUP it doesn't seem to work, it treats it as a file which it can't open...

Could someone tell me why?

What SketchUp version do you have? Do you still have the old "Google" SketchUp or do you have the newest version? You cannot simply post here: "HELP" without giving any exact details about your current version, etc.

It's possible that newer (or older) versions of SketchUp aren't working well with .skp files.

That's what happens if concerns like Google gives not a crap to their program, but simply leaving it untouched and sell it to other idiots. And then of course, they do their own crapload to it, making older saves incompatible.

Your layout has been removed.
Originally posted by Kazeshin

"quite bad" is expressed too nice, lmao.
i might do one, if i get bored, but that tutorial has to cover behavior scripts too, because you'll need them, before you can actually do something with ASM. if i'd do one, i'll do it in earliest 1 week, because i've got to decode level scripts before.

Well, I can't really say anything to it, as I didn't see the tutorial yet. But if the most people hate it, then it's likely the tutorial is bullshit.

If you mean by "behavior scripts" the original stuff provided by VL-Tone, BGNG, etc. in the original SM64 Hacking docs, then you're 100% correct. Most people don't get what he meant, but explaining it would be a really good start into SM64 Hacking. Maybe explaining on the side how Hex Editing works, what the hexadecimal(base 16 digit system) is, etc.

Even if MIPS is a RISC processor, it can be really confusing for beginners. But later they will love it, as it's far easier than a CISC processor. That's for sure.

Your layout has been removed.
This is really interesting, and I'm doing it since a while. Maybe some people heard of the "Torque Game Engine". It's an old 2007 version of the game engine by GarageGames. If you don't know exactly what I mean, you maybe have heard of Torque3D, which is the newest version of the engine. Torque and another engine had some "war" going on. It was Unity vs Torque. Unity offers a lot more than Torque currently and so I think we all know, that Unity is far better than other game engines here. However, this year GarageGames made points with their "free" release of the game engine to the public, giving it out under MIT License.

Now, I've been reverse-engineering the old version of the engine and I choosed a pretty unknown game community, which haves a great game however: "Blockland". Blockland is similar to games like Roblox, however Blockland was already developed in end 2003, when roblox was still under drawing development. Blockland is a creative building game, you build with bricks there. It's a bit similar to Garry's Mod, more specifically if we talk about the settings where you set the number of max vehicles, max bricks, etc. also you can mod Blockland with Torque Game Engine's scripting language: TorqueScript.

Now, some people actually said, that Torque Game Engine is surely "impossible" to hack and what they also told me. Of course, the engine was pretty good on overlooking servers and such and the crown of all, it's a client-server architecture. However, I discovered a lot of exploits in there and a lot of "hacky" stuff you could abuse. Some x86 assembly and creating a DLL, which hooks the functions from the game, allowed me some pretty nice stuff there.

Lemme explain:
Part 1 - Reversing Blockland
First of all, before I could start reversing Blockland, I would need to study how the engine works. For this, I needed the source code from the engine. Unfortunatley, the "OLD" game engine source code is no longer available, but the newest one of Torque3D is. So, I went over and found some old source code files from TGE(short for Torque Game Engine). Through this, I studied how the networking works and could discover what code the game developer of blockland has changed in the engine. For example, usually you can compile a .cs file (No, it's NOT C#. It's TorqueScript) to a cs.dso file. Having the source code would allow you to actually write a DSO Disassembler and recreate the code from scratch. So the game creator(aka as Badspot) simply obfuscate the string tables and moved the sections around.

Through a deobfuscator I wrote in Python I could actually get some decompiled strings from the DSO files.

For info, here the script:
def decryptString(size, base):
strTable = ""
magic = [99, 108, 51, 98, 117, 111, 116, 114, 111]
for i in range(0, size):
	strTable += chr(ord(dso[base+i]) ^ magic[i%9])
return strTable.split('\0')

Part 2 - Interfacing with Torque
I add my DLLs to import table of Blockland. This requires a library, like Detours. Our main cpp code can look like this then:

#pragma comment(lib, "detours.lib")

extern "C" {

#undef UNICODE
#includes go here

void WINAPI MyInsert();
typedef void (WINAPI *pFunc)();
pFunc placeToInsert = (pFunc)(0x004A7A60);

typedef void (WINAPI *aFunc)(const char* className, const char* funcName, void *func, const char* usage, DWORD minArgs, DWORD maxArgs);
aFunc addVoidFunction = (aFunc)(0x004A7840); // address inside Blockland.exe for Con::addCommand (void)
aFunc addIntFunction = (aFunc)(0x004A6C50); // address inside Blockland.exe for Con::addCommand (int)
aFunc addBoolFunction = (aFunc)(0x004A6CF0);// address inside Blockland.exe for Con::addCommand (bool)

    case DLL_PROCESS_ATTACH: // upon attaching to Blockland.exe
         DetourAttach(&(PVOID&)placeToInsert, MyInsert); // insert our code at placeToInsert

__declspec(dllexport) void __cdecl redundant(void);
void redundant() { }//only necessary to import DLL into Blockland.

void WINAPI MyInsert()
   addVoidFunction(NULL, "myFunction", funcToCall, "Usage", 1, 2);
   __asm add esp, 18h


As you can see in this code, the offsets for void, integer, and boolean functions are 0x004A7840, 0x004A6C50, and 0x004A6CF0 respectively. There are other types that I'll add in later, but I haven't gotten around to it / needed them yet. But that shows you how to call them. After calling them there's still some stuff left on the stack so you need to manually push it off by adding 24 (18h) to it.

Then, you can also bind a global variable to an address like so:
typedef void* (WINAPI *addVar)(const char* name, S32 t, void* dp);
addVar addVariable = (addVar)(0x004A7060);

typedef void (WINAPI *pFunc)();
pFunc mGravity = (pFunc)(0x712DF8);

addVariable("mGravity", 8, mGravity);
__asm add esp, 12

8 is the type for integer, I'll update with the types for strings etc later. This example will modify gravity when you change $mGravity. Default is -20.

To call a function, you either use eval or call. I use call in this case:

typedef void (WINAPI *vCall)(S32 argc, const char* argv[]);
vCall tCall = (vCall)(0x004A7120);

const char* args[] = {"messageAll", 0, "Message!"};
tCall(3, args);
void *garbage;
__asm {
   pop garbage
   pop garbage
   pop garbage

It's necessary to pop three things off the stack into a garbage void variable. Torque doesn't do this automatically, so you have to clean up the stack manually. When calling a function from C++, you'll want to include an array of the arguments preceded by the number of values in that array. In this case, we're essentially doing call("messageAll",0,"Message!"), so there are 3 arguments. Eval works similarly, with the offset 0x004AA680. For your argument list, you'd do something like const char* args[] = {"echo(\"hello\");"}; and call tEval(1, args);

And the result of my DLL Injection, allowed me to use an aimbot and use a floating cheat, that makes me float (stuck) if you press the F5 key:

(Click on pic to see it in full size)

I also put in ESP and a wallhack, to go through walls.

In my latest work, I even found out on how to crash a server immediatley just by a press of a button. It's mainly an object(unused one), which the server cannot handle and this will make it crash, of course.

And therefore, Torque Game Engine is a "good" and "safe" engine, but it's not impossible to play around with it.


Your layout has been removed.
From what I've seen I can't really say anything big to it, but quantitative it is an okay. But qualitative it losts to me. It's nothing against you, but it's not like, we're going to party every hack here. We only party those hacks, which have a very good quality. Of course, I also like SM64 Hacks, with original levels. But if you're about to do that, you should offer atleast some good object design there.

We should get some definitions about SM64 Hacking, so people won't be surprised when looking into topics like these.

For example, try to write something like "Vanilla" (ex.: [Vanilla] Super Luigi 64: Bowser's Serious Revenge [WIP] ) in your topic title, so people can already get an overview of what to expect in this topic, in this case, a vanilla SM64 Hack with the original SM64 levels.

Your layout has been removed.
Originally posted by Maxx
Cool stuff.

Torque Game Engine is surely "impossible" to hack

People actually believe this. Name one thing that isn't hack-able, really? If the client has any control at all, it is hack-able to some extent.

Even advanced systems like VAC (which are cool) are circumvent-able.

That's what I mean. Reverse-Engineering Blockland was a test to prove, that even Torque Game Engine actually IS hackable. And see, I've really got it working after 4-6 months. (I know I spend too much time on reverse-engineering things I don't even need later, lol. But that's my hobby and it's actually not different than sitting on a hack for 2 years and release it later so OTHERS can play and use them. Lel)

A question:
Are you the user "Maxx" on Blockland Forums? Just asking out of curiosity.

Your layout has been removed.
Nice Tutorial. #smw{:TUP:} However, you should've explained the part, you were subtracting -12 (Hex) from Stack. Even if it's not important for the start, you could summary it.

SW RA, $0014 (SP)

and the end code:
LW RA, $0014 (SP)
ADDIU SP, SP, $0018

On one side I agree, beginners cannot really make any profit of it. But they more they know, the better they can make use of it in future and move on, on their development to SM64 Hackers. Of course, there are exceptions, that completely fail as miserable SM64 hackers and like to do the worst edits to their ROM ever.

For those who are that badly curious:
This code ensures, that our return address is safely stored and not lost while we code + it won't write into the stack by prior functions. However, it's only needed if we use our current subroutine to call another subroutine. (Logic: If you do a JAL in a subroutine, the old return address will be replaced and this can end "horribly" So the code subtracts $12 (Hex) from Stack and saves it to the $14 part in stack. If the "main" subroutine is done, then the original return address gets load from stack again and the stack will be added with $0018 and THEN it jumps back to the return address.

Your layout has been removed.
For those who are interested:

void __fastcall Hooked_OnRender(DWORD* thisPtr, void* blank, DWORD arg1, DWORD arg2, DWORD arg3)
		GuiPtr = reinterpret_cast<DWORD&>(thisPtr);
		PlayGuiPtr = GetParentBL(GuiPtr);
		MatrixF mat;

		DWORD contPtr = *ConnAddr;

		//in order to do eye tests, we need to get the camera's transform
		//since this function is a __usercall, it needs to be 10x more
		//complicated than just calling it normally. In a __usercall,
		//the registers are previously loaded before the function is called
		//in this case, ECX, ESI, and EAX

			MOV eax, contPtr;
			ADD eax, -0xA0;
			MOV esi, eax
			LEA eax, mat
			PUSH eax
			PUSH 0
			MOV ecx, esi
			CALL TransAddress

		CURRENT_FONT = *(DWORD *)((*(DWORD *)(*(DWORD *)(PlayGuiPtr + 19) + 164)) + 52);
		DWORD player = GetLocalPlayer();

		DrawServerESP(mat, player);

		return OriginalRender(thisPtr, arg1, arg2, arg3);

This code is drawing the HealthHud and the ESP. The camera fix point, for the aimbot, is being set in the asm code. However, it's an _usercall, which is fucking 10x times more complicated than usually. In _usercalls the registers are loaded before the actual _usercall.

Your layout has been removed.
Originally posted by Kazeshin
well, your answer is not correct at all;
at first, it subtracts 0x18, which is pretty important, because otherwise the stackpointer would get messed up and this whole thing wouldn't make any sense at all;
i didn't wanted to explain it so far, because i first got to explain LWs etc, before i'll explain such things.
important is, that you can also save it to $00 or something in the stack, you'd have to ADDU $FFFC then. this would allready be enough, if you don't have to save anythign into the stack. part 2 will come tomorrow and i'll explain button activators.

Wait, 0x18 is decimal. I'm it is -12 in Hexadecimal. Whatever. I simply explained your code as it stands there. Mistakes happen. Well.

Yes, I was explaining "your" code. It's obvious, that you could have chosen others like $00, as you said.

Damn, well. Let's make a simple summary without going any further:
That code is generally used, when calling another subroutines in a subroutine. (In this case: Only if we're going to use another JAL in our subroutine) It simply ensures, that the "original" return address isn't overwritten. Could we agree both here and let this count as a summary? If not, then I don't really care. It's your tutorial.

Your layout has been removed.
Originally posted by Kazeshin

but ADDU FFE8 is subbing 0x18; in dec it would be 24. to calculate the number, calculate 0x1000 - 0xFFE8; you'll get 0x18.

(You probarly meant 0x10000)

Woops. My bad. Just noticed it now. I feel ashamed.
0x10000 - 0xFFE8 = 0x18 -> 24 in decimal.

Your layout has been removed.
Originally posted by JackTheSpades
You could try resizing the image a little. It stretches the tables.
Just do <img src="link here" width="500px">
Note, that the " are mandatory.

Woops, I didn't take note of that. Well, it's fixed. Thank you.

Your layout has been removed.
Nice part, Kazeshin!

A question:
Do you have some source code files from messiaens/fraubers folder? (He released it a while ago on Jul, but took it down) I'm actually searching for the fire mario code, he made in C.

Your layout has been removed.
Here's a list of some signatures. What a signature is, is explained inside the code (aka comment line)

	//signatures are just a set of opcodes inside the code that we scan for when we init
	//It's very dynamic and will still return the correct address even when the game updates,
	//unless they actually made changes to the function

	FUNC_GETCLASSNAME = (GetClassNameFn)BLSigScan("\x8b\x4c\x24\x04\x8b\x01\xff\x10\x8b\x40\x20\x85\xc0\x75\x00\xb8", "xxxxxxxxxxxxxx?x");
	FUNC_PRINTF = (PrintfFn)BLSigScan("\x8B\x4C\x24\x04\x8D\x44\x24\x08\x50\x6A\x00\x6A\x00\xE8\x00\x00\x00\x00\x83\xC4\x0C\xC3", "xxxxxxxxxxxxxx????xxxx");
	FUNC_GETVARIABLE = (GetGlobalVariableFn)BLSigScan("\x56\x8b\x74\x24\x08\x85\xf6\x74\x00\x8a\x06\x84\xc0\x75", "xxxxxxxx?xxxxx");
	FUNC_SETVARIABLE = (SetGlobalVariableFn)BLSigScan("\x56\x8b\x74\x24\x08\x80\x3e\x24\x8b\xc6\x74\x00\x56\xe8", "xxxxxxxxxxx?xx");
	FUNC_GETID = (GetIDFn)BLSigScan("\x8b\x44\x24\x04\x8b\x40\x20\xc3", "xxxxxxxx");
	FUNC_GETNAME = (GetNameFn)BLSigScan("\x8b\x44\x24\x04\x8b\x40\x04\x85\xc0\x75\x00\xb8", "xxxxxxxxxx?x");
	FUNC_GETCOUNT = (GetCountFn)BLSigScan("\x8b\x44\x24\x04\x8b\x40\x34\xc3", "xxxxxxxx");
	FUNC_GETSHAPENAME = (GetShapeNameFn)BLSigScan("\x8b\x44\x24\x04\x8b\x80\xbc\x05\x00\x00\x85\xc0\x74\x00\x8b\x0d", "xxxxxxxxxxxxx?xx");
	OnRender = (onRenderFn)BLSigScan("\x81\xec\x00\x00\x00\x00\x53\x8b\xd9\x8a\x83\xc9\x00\x00\x00\x84\xc0\x55\x56\x57\x89\x5c\x24\x14", "xx????xxxxxxxxxxxxxxxxxx");
	DrawRect = (DrawRectFn)BLSigScan("\x83\xec\x08\x8b\x44\x24\x0c\x8b\x10\x8b\x48\x08\x03\xca\x8b\x50\x0c\x89\x0c\x24", "xxxxxxxxxxxxxxxxxxxx");
	W2S = (W2SFn)BLSigScan("\x55\x8b\xec\x83\xe4\xf8\x83\xec\x1c\x56\x8d\x44\x24\x08\x50\x8d\x54\x24\x1c\x52", "xxxxxxxxxxxxxxxxxxxx");
	GetParentBL = (GetParentFn)BLSigScan("\x8b\x49\x14\x6a\x00\x68\x00\x00\x00\x00\x68\x00\x00\x00\x00\x6a\x00\x51\xe8\x00\x00\x00\x00\x83\xc4\x14\xc3", "xxxxxx????x????xxxx????xxxx");
	DrawRect_B = (DrawRectNoFillFn)BLSigScan("\x83\xec\x08\x8b\x44\x24\x0c\x8b\x10\x8b\x48\x08\x8d\x4c\x11\xff\x8b\x50\x0c\x89\x0c\x24", "xxxxxxxxxxxxxxxxxxxxxx");
	ClearBitmapModulation = (ClearBitModFn)BLSigScan("\xa2\x00\x00\x00\x00\xa2\x00\x00\x00\x00\xa2\x00\x00\x00\x00\xa2", "xxx????x????x????x");
	SetBitmapModulation = (SetBitModFn)BLSigScan("\x83\xec\x10\x8b\x44\x24\x14\xf3\x0f\x10\x00\xf3\x0f\x10\x0d\x00\x00\x00\x00\x0f\x2f\xc1\xf3\x0f\x10\x50\x04", "xxxxxxxxxxxxxxx????xxxxxxxx");
	DrawTextBL = (DrawTextFn)BLSigScan("\x8b\x44\x24\x14\x8b\x4c\x24\x10\x56\x8b\x74\x24\x10\x50\x51", "xxxxxxxxxxxxxxx");
	ConnAddr = *(DWORD**)(BLSigScan("\x89\x0d\x00\x00\x00\x00\x74\x00\x68\x00\x00\x00\x00\xe8\x00\x00\x00\x00\x68", "xx????x?x????x????x") + 0x2);
	TransAddress = BLSigScan("\x53\x8b\xd9\x8b\x83\x40\x02\x00\x00", "xxxxxxxxx");
	addFunction = (AddCommandFn)BLSigScan("\x8B\x44\x24\x04\x56\x50\xE8\x00\x00\x00\x00\x8B\xF0\xA1\x00\x00\x00\x00\x40\xB9\x00\x00\x00
x46\x14\xC7\x46\x00\x00\x00\x00\x00\x89\x4E\x28\x5E\xC2\x14\x00", "xxxxxxx????xxx????xx????x????x????xxxxxxxxxxxxxxxxxxxxxxxxxxx?????xxxxxxx");
	stringtableptr = (DWORD*)BLSigScan("\x8B\x0D\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x50\x8B\xCE\xE8\x00\x00\x00\x00\x5E\xC3", "xx????x????xxxx????xx") + 0x2;
	BLGetNextMove = (GetNextMoveFn)BLSigScan("\x83\xB9\x00\x00\x00\x00\x00\x7E\x05", "xx?????xx");
	ClampMove = (ClampMoveFn)BLSigScan("\x51\xF3\x0F\x10\x0D", "xxxxx");
	gClientContainer = *(DWORD*)BLSigScan("\x8B
\xE8\x00\x00\x00\x00\x5E\xC3\xB9", "xx????xxxxxxxxx????x????xx????xx????xxx") + 0x2;
	CastRay = (CastRayFn)BLSigScan("\x81\xEC\x00\x00\x00\x00\x8B\x15\x00\x00\x00\x00\xF3\x0F\x10\x05", "xx????xx????xxxx");
	AddVariable = (addVariableFn)BLSigScan("\x8B\x44\x24\x0C\x8B\x4C\x24\x04\x50\x6A\x08", "xxxxxxxxxxx");
	FUNC_EVAL = (EvalFn)BLSigScan("\x8A\x44\x24\x08\x84\xC0\x56\x57\x8B\x7C\x24\x0C", "xxxxxxxxxxxx");
	GLOBAL_LOSMASK = *(DWORD*)(BLSigScan("\x8B\x0D\x00\x00\x00\x00\x8D\x84\x24\x00\x00\x00\x00\x50\x51\x8D\x54\x24\x34", "xx????xxx????xxxxxx") + 0x2);
	GLOBAL_CLIENTCONTAINER = *(DWORD*)(BLSigScan("\x81\xFE\x00\x00\x00\x00\x8B\x84\x24", "xx????xxx") + 0x2);

If I wanted to set a variable, I write the stuff as following:
FUNC_SETVARIABLE("BLHack::aimbot::shapeNameColorFilter", "0");

Where "BLHack::aimbot::shapeNameColorFilter" is the variable (Actually a bit different here, we're talking here about members in TorqueScript) and the "0" is the value we set it to.

Your layout has been removed.
It simply questions, if you've got balls.
Nothing to explain at all.

Your layout has been removed.
Originally posted by p4plus2

tool 2) (patcher64)
This tool does not yet have a demo as I have just started development, but I want feedback. This tool is going to be a direct C patcher that can take the output elf file from GCC and directly patch it to SM64. Currently, this is my target setup. What do you all feel about the syntax for hijacking? Is there any way that you feel it could be improved?

This tool is a bit brief and incompletely because I do not have access to all of my resources from class. But, I needed to kick it off somehow. Feedback is appreciated as it will enable you to get a tool closer to what you all would like. Especially on patcher64 as it has important implications.

This. A patching tool for C coding is a really nice thing, I would like to see. I'm currently experimenting and writing a kind of pistol in C. It's not done yet and really buggy, but it's damn impossible for me to patch all these 100-300 lines of GameShark into the game by hand without making mistakes.

Specific Details:
You read the ELF file, as you said. I think you know, if the code is compiled, it usually outputs a .txt file with the GameShark code.
In the linker file, called: "mario64.x" is following:
OUTPUT_FORMAT ("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
EXTERN (_start)
ENTRY (_start)

   /* Start address of code is 1K up in uncached, unmapped RAM.  We have
    * to be at least this far up in order to not interfere with the cart
    * boot code which is copying it down from the cart

   . = 0x80400000 ;

I may also mention, that there's a hook file, that's added to the beginning to the text file if the code's compiled. It ensures, that the code isn't load before mario is not being controlled by the player.

812CB26C 0C10
812CB26E 0000
812CB278 1000
812CB27A 0040

(What it does is simply replacing something useless in mario's behavior with a "JAL 0x80400000" opcode. I think it's obvious what it does)

The header files, including the linker file and the example C code for hello world is included here:
You can also look into the Linker file and see the rest of the code. It mostly includes the function prototypes from explode.h that are being "linked" to the game address of SM64.

extern void  HideObject();  /* hides current object by ORing 0x01 at offset 0x02 */

HideObject = 0x8029F620 ;

After this, your compiled C code starts.
Ex.: Hello World in C, compiled:
812CB26C 0C10
812CB26E 0000
812CB278 1000
812CB27A 0040
81400000 27BD
81400002 FFE8
81400004 AFBF
81400006 0014
81400008 AFBE
8140000A 0010
8140000C 03A0
8140000E F021
81400010 3C1C
81400012 8040
81400014 279C
81400016 0050
81400018 2404
8140001A 0032
8140001C 2405
8140001E 0032
81400020 3C02
81400022 8040
81400024 0C0B
81400026 59B0
81400028 2446
8140002A 0040
8140002C 03C0
8140002E E821
81400030 8FBF
81400032 0014
81400034 8FBE
81400036 0010
81400038 03E0
8140003A 0008
8140003C 27BD
8140003E 0018
81400040 4865
81400042 6C6C
81400044 6F20
81400046 576F
81400048 726C
8140004A 6400
8140004C AAAA
8140004E AAAA

Your layout has been removed.
Pages: « 1 2 »
UGotBalls' Profile - Posts by UGotBalls

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Super Mario Bros. X Community
  • Mario Fan Games Galaxy
  • sm64romhacks