Realm of the Mad God

I decrypted the .swf and was able to view the raw code in Sothink, flawlessly. So, I decided that the best way to learn what I was doing was to "reverse engineer" the AoB codes from other builds including your glitchy one, Lithium.

In most cases: If you decrypt the .swf, the AoBs change and/or the actual AS code changes. Either way, you're not looking at the same game anymore.

This post was imported from an account that no longer exists!
Previous Name: phreneticus

When they update the build and the AoB values change, what's stopping someone from finding the new AoB values for prior build values and just using the same coding?

Nothing except the hacker's effort. If you forgot what code you changed you have to go find it again. Or perhaps you're simply sick/bored/annoyed at the game.

Are they patching the specific methods of code?

In the several years I've been hacking flash games I've only seen this happen on one game (Transformice) and even then it didn't stop hackers.

Thank you, both. I found your mochi/encrypted tutorial phren, I'll continue to read on.

Well basically, when you decrypt the SWF the addresses change, hence the code changes as well.. You can search all in sothink WITHOUT decryption the swf if you make sure the searching is done in raw mode.

You can search all in sothink WITHOUT decryption the swf if you make sure the searching is done in raw mode.

Not in all cases too. I've seen plenty of games which crash in every search mode.

This post was imported from an account that no longer exists!
Previous Name: phreneticus

I've actually been using Yogda for my latest bytecode searches/modification.. hope someone finds this utility useful.

Anything new? Would really love a no dmg hack thats not glitchy :s

I've actually been using Yogda for my latest bytecode searches/modification.. hope someone finds this utility useful.

Thank you sir.. Now I can actually make sense of some of the variable values.


143f0000 601c 6624 668102d066be01d066c2044f9c1e02
143f0000 6208 d0 66c204 6144 10330000 66c2044f9c1e02

Original
//60 1c
_as3_getlex _-KD
//66 24
_as3_getproperty gs_
//66 81 02
_as3_getproperty gsc_
//d0
_as3_getlocal <0>
//66 be 01
_as3_getproperty bulletId_
//d0
_as3_getlocal <0>


Changed to ..
//62 08
_as3_getlocal <8>
//d0
_as3_getlocal <0>
//66 c2 04
_as3_getproperty ownerId_
//61 44
_as3_setproperty
//10 33
_as3_jump 51

Quote from: "Imk0tter"

I've actually been using Yogda for my latest bytecode searches/modification.. hope someone finds this utility useful.

Thank you sir.. Now I can actually make sense of some of the variable values.


143f0000 601c 6624 668102d066be01d066c2044f9c1e02
143f0000 6208 d0 66c204 6144 10330000 66c2044f9c1e02

Original
//60 1c
_as3_getlex _-KD
//66 24
_as3_getproperty gs_
//66 81 02
_as3_getproperty gsc_
//d0
_as3_getlocal <0>
//66 be 01
_as3_getproperty bulletId_
//d0
_as3_getlocal <0>


Changed to ..
//62 08
_as3_getlocal <8>
//d0
_as3_getlocal <0>
//66 c2 04
_as3_getproperty ownerId_
//61 44
_as3_setproperty
//10 33
_as3_jump 51

what hack is this?

The buggy invincibility, I think it's right. Only problem with that Yogda program is when I save the swf file..
assemblegame client.swf whenever i load , it seems to want to connect to the test realm (broken image removed)

The item cannot be picked up when no damage Huck is used and it is inconvenient.
Please correct it by all means.

If you dump the swf after making modifications, all the modifications will be saved to the swf.. That's how I debug most of my modifications when they don't work.

I know but I can't log on the real 108 servers to be able to debug them lol. Some reason it thinks i'm on the test realm when id ownload the SWF file.

Here's a detected one..
Haha you get deleted using this one.


29B096c2039402c2021203000029D07611080000
29B096c2039402c2021003000029D07610080000
invinci

Just replace the first occurance, i didn't tack on the extra bytes.

I figure it's about time:

Invincibility (UNDETECTABLE)
143f0000601c662466
1389fdff103b000066