General Discussions

Of course, but it is already been established early in the thread that this game is more likely requires code-shifting.

Well technically code-shifting requires code injection also but meh :P

thanks.

1- What about offline patching? is that illegal? (directly changing the content of the file in harddisk)

2- As I said, if you read my previous post, the machine code instructions I'm trying to change is like a virtual machine with its own instruction set and is NOT meaningful as x86 code.

And of course, you can change 04 to 90 (nop) as long as you change the consequent related bytes to 90 too. That way it won't break anymore. But then again, I am trying to patch an Intermediate Language (.NET) which is absolutely not x86 code.

I'm trying to have you look at the code not as a set of x86 instructions, because it is IL. Have you ever used .net or ildasm? (intermediate language diassembler)

take a look at this:
This is the original "Appearance" of 12 bytes of code in memory view of CE:

// Total bytes used is 12.
add ah,[edx] // 02 22
add [eax],al // 00 00
add [eax],al // 00 00
jnl 07ab3afc // 7D 23
or [eax],eax // 09 00
add al,2a // 04 2A


These 6 lines are translation of these bytes: 02 22 00 00 00 00 7D 23 09 00 04 2A

but notice the same bytes in memory that are meant for a JIT language such as .NET languages. The same bytes are translated like this :

.maxstack 8
IL_0000: /* 02 | */ ldarg.0
IL_0001: /* 22 | 00000000 */ ldc.r4 0.0
IL_0006: /* 7D | (04)000923 */ stfld float32 (this variable is set to zeo)
IL_000b: /* 2A | */ ret


so now I want to make everything 00 except the last 2A. And don't tell me 00 is another x86 instruction, because this is not x86. In IL code, 00 means nop.


Now that I clearly showed that you can not look at the memory view of CE as x86 instructions (for this game), I myself can conclude that you can not look for x86 code in memory and replace it with instructions!

You should be looking for array of bytes, and replace it with array of bytes. That is what I'm asking you guys. How to do that?

[Edited by AramAz, 5/9/2010 10:16:20 PM]

[Edited by AramAz, 5/9/2010 10:55:25 PM]

[Edited by AramAz, 5/9/2010 10:55:50 PM]

[Edited by AramAz, 5/9/2010 10:56:33 PM]

This game is awesome. It is totally worth paying 20$. It has 15 levels which I managed to finish in less than 3 hours by cheating .

I have created many byte patchers for games that simply remove the code writing to game attributes like lives, ammo, etc. I usually make them when I see no scope for more than 1 or 2 options in a game. But the negative factor is that it can't be toggled straight away, you need to make a backup.

Also there are terms known as "Tweaking" and "Modding" which deals with putting changes in files. And that does not make it illegal. Even people in the official game forums discuss about it! Only when it comes to removing game protections from executables does make things illegal.

I have tried my hands on Max and the Magic Marker. The game does not use code-shifting, the codes are loaded within its own main executable, not with an extended .dll! Marker ink is hard coded here, so don't bother searching for it - You'll end up crashing the game or just making a "Visual" only option. You need some reversing skills at this.

[Edited by HonestGamer, 5/9/2010 10:58:56 PM]

Thanks for your post. I've already reversed, diassembled and found the corresponding bytes and patched it in the memory by hand and it works perfectly with no crashing.

What I need to know, is how to make that memory searching and patching in ce so it won't break next time i load the game.

I already know how to not let that monster suck your ink, as well as how to be able to get scores and save the game even when usiung cheats from the cheat menu.

But notice this game will revert to CLR environment, so CE can't reverse it for you, nor it can replace its code.



And the logic code is not inside the main program. It is inside a .dll file. I know becuase i tried and patched it in memory and it works.

[Edited by AramAz, 5/9/2010 11:03:11 PM]

Here is the part you misunderstand, doesnt matter what language the game is coded in, it still has to go through the CPU ultimately and that is what your debugging, the mnemonics of the CPU.

So even in C++, VB, .NET, etc they all can be debugged, after all you can code in a language and later you have to compile to a binary file.

As for ILDASM, that is primarily for PE files.

Unless what your trying to say is the game is run via a .net engine running it. Then you will have to go a long way about things.

[Edited by DABhand, 5/10/2010 7:11:00 AM]

Exactly. It is based on .NET, but the exe file is not .net, only the .dll parts of that game.

I'm catching the .dll content in memory before it is compiled into native code, as you may know .net uses a JIT compilation scheme.

And of course understanding the logic of the game before it goes to native code is much easier since it is .net and the original code can be reflected using many tools.


Long story short, how to search memory for an array of bytes and patch with CoSMOS?

or if you know another tool that can do this?

Otherwise I'm going to create my own memory patcher and tell users to run the trainer before running the game.

Regards,
Aram

Well the binary that runs the game will have to call on the .dll's. So you can technically find where it makes those calls through the binary and from there figure out a way of getting addresses to manipulate.

Again I dont have the game itself to check, and dont think ill buy it either. Still strange a game that is also available on the Wii would use a JIT compiler of sorts.