Making AoBs to modify 'var' values?

So I'm not too experienced in mucking about with making hacks etc, but I've dropped in and out of it for a decent period of time (a few years?), so my terminology will probably be wrong in places (or everywhere). This is mainly regarding BTD5

Recently came back and was wondering about whether the var declarations and assignments can have their values changed. I know that in Sothink and JPEXS ffdec, no bytecodes are shown for such areas as (when clicking outside of the array in ffdec)

public class Bloon extends Entity
    {
          private static const maxHealthByType:Vector. = Bloon.Vector.([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 10, 200, 700, 4000]);

Firstly, for such sections (but without bytecodes visible), how would one go about modifying these sections of code?

Seconds, with the above example, if I edit the array in ffdec and save it then load, the health values in-game change as expected, however, when I try to change it via CE in the browser, I can find and modify the AoB but there is otherwise no effect. I often read about having to freeze the game during (?) or just after the loader to start using AoB hacks, but I don't think I have ever gotten such hacks to work... 

Anyway, the original code for the array was (with extra either end):
; 64
getglobalscope
; 24 01
pushbyte 1
; 2a
dup
; 2a
dup
; 24 01
pushbyte 1
; 2a
dup
; 2a
dup
; 24 01
pushbyte 1
; 2a
dup
; 2a
dup
; 24 01
pushbyte 1
; 24 0a
pushbyte 10
; 25 c8 01
pushshort 200
; 25 bc 05
pushshort 700
; 25 a0 1f
pushshort 4000
; 56 0e
newarray 14
; 41 01
call 1
; 68 ed 17

What I mainly was interested in doing was changing the larger values back to 1, so what I did was replace pushbyte 10 (24 0a) with pushbyte 1 (24 01) and then replace the pushshorts with pushbyte 1 followed by nop: 25 c8 01 -> 24 01 02
Would that be a correct? I'm not sure whether this part is wrong, whether it can be changed (assuming it can since I can do it locally) or whether I am jut failing at applying the hack.
The codes I ended up with were:
64 24 01 2a 2a 24 01 2a 2a 24 01 2a 2a 24 01 24 0a 25 c8 01 25 bc 05 25 a0 1f 56 0e 41 01 68 ed 17
->
64 24 01 2a 2a 24 01 2a 2a 24 01 2a 2a 24 01 24 01 24 01 02 24 01 02 24 01 02 56 0e 41 01 68 ed 17

If someone could give me some pointers (or perhaps see if it works?), it would be much appreciated :)

Constants are probably compiled first thing after the game finishes loading, thus preventing you from easily changing their values. I tried your AoB and it didn't seem to change anything (multi-layered bloons did the normal amount damage when they got through, and they took several hits before popping).

I suggest you stay away from constants unless you plan on using a tool such as Charles or playing locally. Instead, you should focus on functions, references to the constant(s) in question etc. Pretty much anything other than constants.

Modifying a function
After searching through a few classes I noticed a function called setHealth on the levels:Level class. Please note that this isn't the only function that modifies your health, so what we're about to do may not help a lot / at all.



What we want to change is the first line in the function body: this.health.value = param1;
We can either NOP it or swap param1 with 100 or some other arbitrary integer.

The byte code for this line can be seen below.



Now we merely need to find a unique AoB and change 61 4D to 24 64 (pushbyte 100).

Modifying function calls
Alternatively, we can modify every call to setHealth. That's not really feasible in this case since the actual parameters vary in length.



Modifying variable references
Usually, variables such BTD5's health in the levels:Level class are private and thus only accessed externally through functions. Evidently, the developers of BTD5 don't care about encapsulation. Assuming health is only accessed directly inside the levels:Level class, and maybe even if it's accessed elsewhere (I can't remember how that works in AVM2), we can make sure health is always set to the same value, or make it so that it only ever increases. This may require multiple AoBs, so it may not be ideal either.



Modifying conditional expressions
If the game has a condition such as:

if(health <= 0){
    trace("You lose!");
    // Do stuff...
}

Changing <= and/or 0 may help.

Btw, you should always provide a link to where you play the game. Kongregate has a different version of the game than Ninjakiwi, so your AoB doesn't exist in Kongregate's version. Also, a succinct summary of how you found the AoB, how you used it etc. would help us retrace your steps. The easier your post is to understand, the more help you'll get :)

Alright, thanks for that :) On the topic of playing locally, are there tools which allow you to skip those? I know of bmanatee's sitelock tool, but I never got it working due to port errors (and assuming they are probably too hard to edit out for someone such as myself).

Removing a sitelock is fairly easy. There's a very thorough example for complete beginners here, which explains every step by step how to remove sitelock from a specific game.

If I were to remove a sitelock I'd first search for the url I was playing the game. Not the whole url, i.e. just "kongregate", "armorgames" etc. If there's a sitelock in place, chances are the allowed sites are listed somewhere. Use a hex editor to NOP whatever code needs to be removed, then open the game and see if it works. If it doesn't work, Google 'flash sitelock' and search for some of the keywords used in the articles etc. you run across. One such keyword is 'domain'. Search for these keywords in the code and replace it with a hex editor.

If it still doesn't work, or you can't figure out what to change, just post here again with as many details as possible. But put some effort into it first ;)

I've spent some extensive time in the past trying to get the sitelocks off of BTD5 (http://ninjakiwifiles.com/Games/gameswfs/btd5.swf?v=160512-2, requires you to load the loader in this page to run http://ninjakiwi.com/Games/Tower-Defense/Play/Bloons-Tower-Defense-5.html), and had initially come to the conclusion that in the ninjakiwi -> utils -> StandardStuff, there is another swf that has been converted to base 64 (?) or otherwise encoded, that is then decoded on running the game that manages the site-locking. I assumed this because I afterwards dumped additional swf files from the flash instance, and one contained the visual assets for the splash screen and lock/redirect. It's likely I got the wrong interpretation of it though and that isn't very related.

I'm aware of the settings script file with domain locking and arrays of site names listed clearly, but these are again part of the static constant declarations and don't have bytecodes shown. I've tried changing some of them in ffdec in the past but it just ended up with crashing, but I'll try and take another look at the thing on the whole later when I have some more spare time.

One thing I was wondering was what should you use for your local 'url'? For example, the game allows armorgames.com; if you were to replace that to run locally, what should it be? I'm led to believe it should be localhost, but want some 'confirmation' on that.

Regarding online resources, I've previously found things regarding sitelocking quite sparse, with the majority being vague about locking or jut reviews of securing tools - not much to run off. Removing sitelocks gets even more rare with just that one Youtube video about it.

Otherwise, once I get knee-deep in it and need some help, I'll be back with some actual details about what I need help with :)


 

If you can use Charles or other debugging proxy , you can map your local modfied swf with the original swf, so whenever the browser want to read the original swf, it read from your local file instead.
In this way, you save time to disable sitelock, and not all flash can be disable easily, eg. if main swf read more files (resource etc.) from relative path that failed to setup locally.
 

I'm aware that that does work, but it isn't as practical as removing the sitelock would be in the long-run. Thanks though :)

that depends on how long you plan on playing it offline. if you only wanna play it for a month or so and beat it, charles is perfect. if you plan on using the same swf for a year or two, removing the sitelock would probably be better, although charles would still probably work.

I just feel that it'd be more practical to load up the swf locally in order to test out things more efficiently, rather than loading up the game in the browser. I haven't used charles and am not sure completely how it works compared to other similar software, but I've got another debugger (fiddler) and using that auto-responder I would rather not have to use it all the time for this purpose (mainly because I need to clear cache and reload to get the page to fetch again). If the sitelock can be cracked then it shouldn't be too hard to do it again in the future assuming it won't change much.

It sure is a pain in the ass if the game loads certain assets. For most games, however, the assets should be fairly well organized so you just have to download a few folders. If the paths are absolute you will, of course, have to change them.
 

I'd probably just change the if statements.

Example:
if(url != "konghack.com"){
    gotoAndPlay(sitelockScreen);
}

NOP it all or change != to ==.

Changing it to 'localhost' or '*' should get it to work, but like KH said, just changing the if statement should work. I've seen a lot of games that will have something similar to KH's example...

if(url == "localhost"){
    gotoAndPlay(sitelockScreen);
}

The same method applies, just change the == to !=, no need to overcomplicate things and get yourself confused. There are many different ways to go about it, sometimes the easiest solution is the best.