Flash AS3 Class overriding template and tutorial

The biggest problem with class overriding I have found so far is that large classes can take a lot of work to "fix" to work with class overriding. So, I have created a template for class overriding that can make this process a vast amount easier.
It certainly has it's limitations, but where it works, it works well.
To be able to use it properly, you need to have a pretty good understanding of how it works.
I'll start with a quick overview of how it works, don't worry too much if you don't understand it properly yet:

A custom loader dynamically generates a SWF containing a single "nullified" class that has no methods or properties and uses class overriding to nullify the document class in an instance of the game SWF (this instance is used solely for accessing the original, unmodified classes in the game).


Template classes use the proxy extends hack to pretend to "extend" the original class in the game. e.g. if you were overriding the class "Money", the template does this by using the proxy hack to pretend to extend the original "Money" class held in the nullified instance of the SWF loaded by the custom loader.

Classes are overridden by extending the BasicOverrider class that is included in the template. This class and the custom loader do all the hard work for you. Any public methods and variables can now be modified, without having to "fix" any code you're not working with.

Here's a nice little visual explanation for the loader:



With any luck, you now have a decent understanding of how the loader works.
so, onto how the template extender works:



If you need more information, you can take a peek at it's source.

Now, hopefully you understand it's limitations. It cannot access private/protected vars and requires a little work to fix type casting problems (Note: a lot of the time this isn't a problem) due to the nature of how it functions.

Now, here's the mini-tutorial and template download link:
You'll need this SWF and the OverriderLoader template for this tutorial.
I will assume you know everything covered in this tutorial.

Setting up the template is really easy.
The SWF name is "Unhackable.swf" and if you open it up with a decompiler, it'll tell you the document class  is "Unhackable".
open up the Overrider class and change:

 loader.load("SWF NAME HERE.swf","DocumentClassNameHere");  

to:

 loader.load("unhackable.swf","Unhackable");  

Next, we need to fix the stage access problem. Unfortunately, template overriding doesn't work on the document class (because it gets nullified so you can load the other classes without running code), so we'll need to use the old method. We'll use the same code we wrote up in the last tutorial. Chuck this code in a new class called "Unhackable":

 package   
 {  
      import flash.utils.*;  
      import flash.display.*;  
      import flash.events.*;  
      public class Unhackable extends MovieClip  
      {  
           private var Player:Class = getDefinitionByName("UnhackableEngine.Player") as Class;  
           private var Money:Class = getDefinitionByName("UnhackableEngine.Money") as Class;  
           private var ScoreKeeper:Class = getDefinitionByName("UnhackableEngine.ScoreKeeper") as Class;  
           private var player:Object;  
           private var money:Object;  
           private var score:Object;  
           public function Unhackable()  
           {  
                this.addEventListener(Event.ADDED_TO_STAGE,addToStage);  
                return;  
           }  
           private function addToStage(e:Event)  
           {  
                this.player = new Player(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.money = new Money(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.score = new ScoreKeeper();  
                addChild(this.score as DisplayObject);  
                addChild(this.money as DisplayObject);  
                addChild(this.player as DisplayObject);  
                stage.addEventListener(Event.ENTER_FRAME, this.gameLoop);  
           }// end function  
           private function gameLoop(event:Event)  
           {  
                this.money.dealWithPlayer(this.player.playerX, this.player.playerY);  
                this.player.doMove();  
                return;  
           }// end function  
      }  
 }  

Now that that problem's solved, we can get on to using the template for something useful.

We'll make each money pickup give you 100 score.
Now, if you remember, the actual score variable is private, which means that template overriding can't touch it. however, the static "addMoney" method is public and can thus be edited.

So, let's start with a basic overrider template class, then.
Create a new class in the package "UnhackableEngine" called "ScoreKeeper" and give it this code:

 package UnhackableEngine {  
      import OverriderLoaderUtils.BasicOverrider;  
      import flash.utils.*;  
      public class ScoreKeeper extends BasicOverrider {  
           public function ScoreKeeper() {  
                super(getQualifiedClassName(this));  
                origObject = new origClass();  
           }  
           static function addMoney()  
           {  
                origClass.addMoney();  
           }  
      }  
 }  

This is just a basic overrider template class with a wrapper function for the addMoney static method (as all static methods need wrapper functions when using the template). Our goal right now is to get it to compile with this.

So, lets add the line

 var scoreKeeper:ScoreKeeper;  

to our Overrider class to make it all compile together and see what errors we get.
You'll get an error telling you it doesn't want to be added as a child. We've been here before, haven't we? last tutorial?
Change:

 addChild(this.score as DisplayObject);  

to:

 addChild(this.score.origObject as DisplayObject);  

in your Overrider class to make it quit it's bitching. Compile, and it should be happy.

Now all we need to do to make money add 100 score is go to our ScoreKeeper class and change:

           static function addMoney()  
           {  
                origClass.addMoney();  
           }  

to:

           static function addMoney()  
           {  
                for(var i:int = 0;i<100;i++){  
                     origClass.addMoney();  
                }  
           }  

Compile, and you're done!

Here's the finished source code for the tutorial.


Oh, and if you're wondering how to fix static variables, you do something like this:

           static function get varName():Object  
           {  
                return origClass.varName();  
           }  
           static function set varName(value:Object):Void  
           {  
                origClass.varName = value;  
           }  

Where varName is the name of the variable.

The pros of using the template:
- no need to fix any non-static functions
- static functions only need to be redirected, so fixing is much simpler compared to the old method

The cons of using the template
- doesn't work on the document class
- doesn't work on private/protected vars/methods
- type casting is still a problem

Flash AS3 Class injection via Loader

I discovered a new technique for hacking flash games a month or so ago. I've been referring to it as class overriding (simply because class injection could be used to refer to injecting bytecode into a SWF).
It's a fairly simple technique that allows you to have extreme control over a loaded SWF.
I was going to do this tutorial on an actual game, but unfortunately there weren't any games that were good examples, so instead I modified my Unhackable Engine base (designed to be the simplest game possible for testing new security measures/ect in a semi-real environment and easy to port to other languages, the original AS3 version is under 90 lines of code, and the AS2 version is less than 60).
I'm going to assume you have some experience with AS3 and flash. If you don't, the source for this tutorial will be available.

Be warned, this SWF was botched together as fast as possible, and modified to function in weird ways specifically for the tutorial. Don't judge me on the quality of it's code.

Download the "game" used in this tutorial here.

 Anyways, to the tutorial:

The first thing we do is we start with a basic loader template that will load the SWF.

Create a new document class (I called mine Overrider), and put this code in it:

 package {  
      import flash.display.MovieClip;  
      import flash.display.Loader;  
      import flash.net.URLRequest;  
      import flash.system.ApplicationDomain;  
      import flash.system.LoaderContext;  
      public class Overrider extends MovieClip {  
           private var ldr:Loader = new Loader();  
           public function Overrider() {  
                this.addChild(ldr);  
                var urlReq:URLRequest = new URLRequest("unhackable.swf");  
                ldr.load(urlReq,new LoaderContext(false,ApplicationDomain.currentDomain));  
           }  
      }  
 }  

This will load the SWF into our SWFs ApplicationDomain, meaning that classes will be loaded into the same space, and when flash player tries to load a class that already exists in the current ApplicationDomain, the new class is dropped, and the old one remains (which is how this hack works).
Now, compile and run that, and you will get an error.

 TypeError: Error #1009: Cannot access a property or method of a null object reference.  
      at Unhackable()  

let's open unhackable.swf with a decompiler, and see what the problem is.
We know from the error that the error is within Unhackable(), so let's look at the code:

 public class Unhackable extends MovieClip  
 {  
   ...  
   public function Unhackable()  
   {  
     this.player = new Player(int(Math.random() * 300) + 50, int(Math.random() * 200) + 50);  
     this.money = new Money(int(Math.random() * 300) + 50, int(Math.random() * 200) + 50);  
     this.score = new ScoreKeeper();  
     addChild(this.score);  
     addChild(this.money);  
     addChild(this.player);  
     stage.addEventListener(Event.ENTER_FRAME, this.gameLoop);  
     return;  
   }  
   ...  
 }  

Ah, there's our problem. Let me explain for those of us who are unfamiliar with the bugs in the Loader class...
When A SWF is loaded normally (without the Loader class), the document class's constructor is called after it has been added to the stage and therefore has the stage property set. When a SWF is loaded with the Loader class, the document class's constructor is called before it has had it's stage property set, so that refference to the stage:

 stage.addEventListener(Event.ENTER_FRAME, this.gameLoop);   

will throw an error, because the stage variable is still a null object reference (it's null), and as the error states, you cannot access a method of a null object reference.

Luckily, we can fix this quite easily with class overriding.

Create a new class in your default package called Unhackable and copy and paste the code the decompiler generated for that class over.

Now, when you compile that, you'll get about a half-dozen errors. this is ok, and completely normal in class overriding. You see, that class imports other classes (Player, Money, ScoreKeeper) that we don't have in our project. The first solution you probably think if would be to decompile and add every class in the SWF, but that would be a pain in the ass and counterproductive, so we're gonna hack our way through this. the question we need to answer is: How do we access a class we can't import? The solution is simple: using the getDefinitionByName function in flash.utils.*.
so, replace:

 import UnhackableEngine.*;  

with:

 import flash.utils.*;  

getDefintionByName will dynamically find the class for us whenever we need it. so, with a little modification we can fix this class.
replace:

     private var player:Player;  
     private var money:Money;  
     private var score:ScoreKeeper;  

with:

           private var Player:Class = getDefinitionByName("UnhackableEngine.Player") as Class;  
           private var Money:Class = getDefinitionByName("UnhackableEngine.Money") as Class;  
           private var ScoreKeeper:Class = getDefinitionByName("UnhackableEngine.ScoreKeeper") as Class;  
           private var player:Object;  
           private var money:Object;  
           private var score:Object;  

Also, since there are no references to  this new class you've added, by default it won't compile into your SWF, so go back to your document class, and under the class variable definitions, add:

 private var unhackable:Unhackable;  

When you try and compile, you'll get some more errors now, but that's OK, cause we're gonna have to replace the function they're in anyway.
So, onto replacing the function, fixing the stage reference problems and adding the needed type casting.
First, we're gonna move all the code in the constructor to another function, and make that function be called when the object has been added to the stage (using the ADDED_TO_STAGE listener).
replace:

           public function Unhackable()  
           {  
                this.player = new Player(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.money = new Money(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.score = new ScoreKeeper();  
                addChild(this.score as DisplayObject);  
                addChild(this.money as DisplayObject);  
                addChild(this.player as DisplayObject);  
                stage.addEventListener(Event.ENTER_FRAME, this.gameLoop);  
                return;  
           }  

with:

           public function Unhackable()  
           {  
                this.addEventListener(Event.ADDED_TO_STAGE,addToStage);  
                return;  
           }  
           private function addToStage(e:Event)  
           {  
                this.player = new Player(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.money = new Money(int(Math.random() * 300) + 50,int(Math.random() * 200) + 50);  
                this.score = new ScoreKeeper();  
                addChild(this.score);  
                addChild(this.money);  
                addChild(this.player);  
                stage.addEventListener(Event.ENTER_FRAME, this.gameLoop);  
           }  

And now we add some type casting to fix the last 3 errors.
replace:

                addChild(this.score);  
                addChild(this.money);  
                addChild(this.player);  

with:

                addChild(this.score as DisplayObject);  
                addChild(this.money as DisplayObject);  
                addChild(this.player as DisplayObject);  

and compile. with any luck, you have no errors, it compiles, loads the SWF and runs perfectly!
If not, try download the source of the finished code and try and figure out what went wrong.

Congratulations! you've successfully overrided your first class!

Now, onto doing something useful.

We'll double player speed and make it so that each "money" pickup gives us 1,000 points.
First, we'll start with the money hack, because the player speed hack is a little more complicated (If you're feeling confident/bored, you can skip to the player speed hack, as it teaches more important stuff).

This one is simple and straightforward.
you'll need a new package (class locations need to be mirrored) called UnhackableEngine, and in there a new class called ScoreKeeper.

Copy and paste the ScoreKeeper code from the decompiler, add this line of code to your document classes variable definitions to make sure it gets compiled in:

 private var scoreKeeper:ScoreKeeper;  

and compile.
You'll get an error.
Don't worry, it's easy to fix.

Our problem is that variables are not being casted from int/whatever to string, so the compiler is getting shitty with us.

replace the two occurrences of:

 score.text = gameScore;  

with:

 score.text = String(gameScore);  

and compile.
It should compile and work without errors.

Now, let's take a look at the addMoney function:

     static function addMoney()  
     {  
       var _loc_2:* = gameScore + 1;  
       gameScore = _loc_2;  
       score.text = String(gameScore);  
       return;  
     }  

seems easy enough to modify. Let's chuck some 0s in there

     static function addMoney()  
     {  
       var _loc_2:* = gameScore + 1000;  
       gameScore = _loc_2;  
       score.text = String(gameScore);  
       return;  
     }  

and boom, money pickups now give us 1000 score.

Onto player movement, and advanced class overriding!
I'm sure you know the drill by now.
Create a new class in the UnhackableEngine package named Player.
C+P the code from the decompiler, add a reference to the class in your document class, try to compile and see what errors you get.

Ooh, we get a new, nasty one.

The definition of base class Thing was not found.

We have two options here, overriding the Thing class will solve this problem, but imagine if Thing extended another custom class, which extended another custom class, which ended up being a class chain 20  classes long? it would be impractical to override them all.

But how can you possibly get around it? you can't just dynamically extend classes. That goes directly against AS3s standards. Luckily, in AS3 there's this nasty little thing called the Proxy class that goes against all of AS3s conventions, and makes this possible.

Although we cannot actually dynamically extend classes, we can pretend we do using the Proxy class to dynamically pretend we have properties of classes which we actually don't.

I'm going to warn you now, everything's about to get messy. Which is why I'm stalling.

I guess I'll explain the Proxy class a little, seems like it's the best way to teach this.

The Proxy class allows you to dynamically change the behavior of an object. When set up, you can make it so that if a property is accessed and doesn't exist in an object, a proxy function is called that can deal with it. we use this functionality to make an object act as if it has the properties of another object by making any attempt to access a property that doesn't exist on the object go to the object it is pretending to extend.

Hopefully, the code will help explain what I mean for those who are still confused...

First thing we need to do is make the Player class extend the Proxy class.
replace:

 public class Player extends Thing  

with:

 public class Player extends Proxy  

now, add these variables to the Player classes variable definitions:

           public var extendedClass:Class = getDefinitionByName("UnhackableEngine.Thing") as Class;  
           public var extended:Object  

add these functions to the class:

  override flash_proxy function getProperty(name:*):*
  {
   return extended[name];
  }
  
  override flash_proxy function setProperty(name:*,value:*):void
  {
   extended[name] = value;
  }

  override flash_proxy function callProperty(name:*, ...rest):*
  {
   extended[name].apply(rest);
  }

these functions are the backbone of our Proxy hack. We don't actually need most (or any) of them. in most situations, you'll need them, though. There are more Proxy functions you may need in other circumstances, but these are the main ones.

We're gonna have to do quite a bit of modifying to make this class work with us.
Any internal references in the player class to the class it extends need to be changed.

replace:

     public function Player(param1, param2)  
     {  
       fillColour = 11141120;  
       this.playerX = param1;  
       this.playerY = param2;  
       this.addEventListener(Event.ADDED_TO_STAGE, this.addListeners);  
       super(param1, param2);  
       return;  
     }  

with:

           public function Player(param1, param2)  
           {  
                extended = new extendedClass(param1, param2);  
                extended.fillColour = 11141120;  
                extended.drawStuff();  
                this.playerX = param1;  
                this.playerY = param2;  
                extended.addEventListener(Event.ADDED_TO_STAGE, this.addListeners);  
                return;  
           }  

and

     public function doMove()  
     {  
       this.playerX = this.playerX + this.xVel * 5;  
       this.playerY = this.playerY + this.yVel * 5;  
       drawX = this.playerX;  
       drawY = this.playerY;  
       drawStuff();  
       return;  
     }  

with:

           public function doMove()  
           {  
                this.playerX = this.playerX + this.xVel * 5;  
                this.playerY = this.playerY + this.yVel * 5;  
                extended.drawX = this.playerX;  
                extended.drawY = this.playerY;  
                extended.drawStuff();  
                return;  
           }  

and

     private function addListeners(event:Event) : void  
     {  
       stage.addEventListener(KeyboardEvent.KEY_DOWN, this.keyDownListener);  
       stage.addEventListener(KeyboardEvent.KEY_UP, this.keyUpListener);  
       return;  
     }  

with:

           private function addListeners(event:Event):void  
           {  
                extended.stage.addEventListener(KeyboardEvent.KEY_DOWN, this.keyDownListener);  
                extended.stage.addEventListener(KeyboardEvent.KEY_UP, this.keyUpListener);  
                return;  
           }  

As you can tell, the Proxy hack can be a bit messy. sometimes, it's better to just override the class it extends as well. cause now where up to the next problem: type casting.
A Proxy object can't be casted to anything the object it's pretending to extend can. And the addChild function which the player object is given as a parameter to expects a DisplayObject. luckily, we're already overriding the class that calls the function, so go back to the Unhackable class and
replace:

 addChild(this.player as DisplayObject);  

with:

 addChild(this.player.extended as DisplayObject);  

compile that and it should work error-free.

The Player class is FINALLY set up for modification (again, the proxy hack isn't really made for this situation, but it's useful to know how to do it).

One quick modification and we'll  have double player speed.

change

                this.playerX = this.playerX + this.xVel * 5;  
                this.playerY = this.playerY + this.yVel * 5;  

to

                this.playerX = this.playerX + this.xVel * 10;  
                this.playerY = this.playerY + this.yVel * 10;  

And we're done!

Download the source for this tutorial here.

A momentary lapse of progress

So, what's that running through your head right now? something on the lines of "Hey, Bmanatee, you haven't updated this blog in a while... are you dead? What's happening with BPE?" I bet. No? well, why the hell isn't it?

Anyway, BPE has been put on hold while I study for exams (I'll continue working on it near the end of November).
With any luck, strait IP hooks will be added next release (in the form of my pre-hook system). And hopefully I'll do some more work on PEW files, too.
When that's all done and dusted, and I feel the plugin system has been developed enough, I'll move from Pre-Apha phase to Alpha phase and start working on the analyzer part of BPE.

I'm also going to try and write some more complicated plugins for games when I get the time, maybe even a packet-based aimbot. Maybe I'll write a plugin for a game with some basic connection security (eg. data + hash, which would conventionally be nigh impossible to edit using a packet editor without completely replacing the packet).

BPE Plugin Writing Tutorial #1 (Writing your first plugin)

So, I thought it was about damn time I wrote a tutorial on writing plugins for BPE (Mostly because currently I'm the only person who knows how).
Firstly, I've been updating the Wiki, so hopefully between this tutorial and the Wiki, there should be enough information for people to start writing plugins.
 and now the tutorial:

Writing your first plugin.

So, we're  gonna make a nice, simple plugin that simply outputs everything happening on the servers/ports being listened to.
It'll do the following:
Properly set up it's window
Output all sent/recieved packets
Output when connections are opened/closed

Now, let me explain a little about the hook system BPE uses. there are two kinds of hooks:
Hooks called by BPE, and
Hooks called by the plugin.

Hooks called by BPE are utilized by creating a public function in the document class of the plugin.
eg:

 public function sendPacketHook(packet:ByteArray,socketID:int):ByteArray  
 {  
     output.appendText("["+socketID+"] Sent:"+packet+"\n")  
     return packet;  
 }  

That above code would be called every time a packet is sent by the client. the variable "packet" contains the payload (data) from the packet in the form of a ByteArray. socketID is an integer containing the ID of the socket. The function returns the unmodified packet, so no modification is made.

Hooks called by the plugin are utilized by creating a public Function variable in the document class of the plugin, and then calling that variable/Function when you need to.
eg:

 public var updateWindow:Function;  
 public function someFunction():void  
 {  
     updateWindow(550,400,"Debug");  as
     return;
 }  

That above code (when someFunction is called) will scale the size of the window so that the stage is 550 pixels wide and 400 pixels high, then set the plugins window title to say "Debug".

Also note that all used hooks must be specified in the .pep file that goes with the plugin (more on that later, though).

Anyways, I hope that's enough explanation for understanding the hooking system for now. let's get on to making the actual plugin!
I'm going to assume you know your way around Flash and know a little AS3 at this point.
So, create a new AS3 project and a document class called "BPEDebugPlugin".
now, we're gonna be using ByteArray's (for the sent and received data) and TextFields (for the output), so go ahead and add these lines to the includes:

     import flash.text.TextField;  
     import flash.utils.ByteArray;  

Now, we're gonna need to declare a couple variables in the class.
Firstly, since we want to set the window size and title, we want to use the updateWindow hook, so we need to add a Function variable with the name updateWindow.
Secondly, we want a TextField that we can write our outputted data to.
so, add these lines to your class variable declarations

         public var updateWindow:Function;  
         private var output:TextField = new TextField();  

we're gonna make use of the finishPluginSetup hook. this simple hook function is called after your plugins hooks have been set up and your plugin has been added to the stage. it basically tells you it is now safe to use hooks and access the stage.
Chuck this code right after the end of your constructor function:

         public function finishPluginSetup()  
         {  
             updateWindow(550,400,"Debug");  
             output.x = 20;  
             output.y = 20;  
             output.width = 510;  
             output.height = 360;  
             output.background = true;  
             output.backgroundColor = 0xAAAAAA;  
             output.text = "Output\n";  
             this.addChild(output);  
         }  

As stated before, this function will be called once, when BPE has added it to the stage and set up all it's hooks. it calls the updateWindow hook and changes the window size and label. it will then set up the output TextField for use.

Now, let's get to the actually useful hooks. We'll start with the send and receive hooks, since they're super-similar, and quite simple.

         public function recievePacketHook(packet:ByteArray,socketID:int):ByteArray  
         {  
             output.appendText("["+socketID+"] Recieved:"+packet+"\n")  
             return packet;  
         }  
         public function sendPacketHook(packet:ByteArray,socketID:int):ByteArray  
         {  
             output.appendText("["+socketID+"] Sent:"+packet+"\n")  
             return packet;  
         }  

These functions will be called by BPE every time a packet is sent by the client or received by the client. packet is the ByteArray containing the data payload of the packet, and socketID is the ID number for the socket. We'll output the data being sent in the packet.
This is probably a good time to introduce you to BPE's socket ID system. each socket that connects to BPE is given an ID to make them easy to keep track of.
The first socket to connect is given the ID 0
the second 1
the third 2
ect.
The functions then output the sent/recieved data along with the socket ID.
The ByteArray returned by these functions is then run through any remaining plugins and either sent to the client or server depending on whether the packet is being received or sent.
Since we're returning the same, unmodified ByteArray that was the input of the function, the packet is left untouched. if you return an empty ByteArray, the packet is dropped.

Onto the socketOpen and socketClose hooks.

         public function socketOpenHook(socketID:int,address:String,port:int):void  
         {  
             output.appendText("["+socketID+"] Connected to:"+address+":"+port+"\n")  
             return;  
         }  

The socketOpenHook is run every time a socket connects to BPE. it gives you the new socket's ID, the address it's attempting to connect to and the port on which it's attempting to connect to. We'll output the address and port on the server it's attempting to connect to.

Next is the socketCloseHook.

           public function socketCloseHook(socketID:int,closeSocket:Boolean):Boolean  
           {  
                output.appendText("["+socketID+"] Disconnected, "+closeSocket+"\n")  
                return closeSocket;  
           }  

The socketCloseHook is called when the server disconnects the client. The Boolean closeSocket tells you whether BPE plans on disconnecting the client. if true, the socket is to be disconnected, if false, the socket connected to the client will stay connected. We'll return the closeSocket value given to us to let the other plugins or BPE decide what to do with the socket connected to the client.

Now, compile that sucker and we're up to creating the .pep file to load our plugin.

PEP files are like an external header for the plugin. it tells BPE everything it needs to know to run your plugin.
I created a simple little tool making it easy to generate the .pep file for your plugin. you can get it here or on the downloads page.
Open the PEP Builder up (do it in your browser if you have to).
For plugin name, type "BPEDebug".
For SWF Filename, write the name of your SWF (mine is "BPEDebug.swf")
and we need to tick the box next to each hook we used
tick the box next to hookUpdateWindow, hookFinishPluginSetup, hookRecievePacket, hookSendPacket, hookSocketOpen and hookSocketClose.
Once you've done that, click the "Save PEP File" button, and save it to the same location as your plugin SWF.

You're done!
Load your plugin with BPE, hook a server and port (web servers are the easiest for testing),  and if it works, give yourself a pat on the back.
If it doesn't work, try again or  leave a comment.

Here's a link to my finished source.

BROPlugin release

Made a new plugin. BROPlugin, a hack for XGen's game Blast Rage Online.
 you can download it here or from the Downloads page.
Currently, it only has Godmode. I might add my reload and wall hack at a later date.
To run this, you'll need Adobe Air and BPEV1.1.
you need to hook www.xgenstudios.com on port 80 to make this work.
Here's a quick video tut on how to set it up.

It's not open-source cause that would make it too easy to patch

BPE Pre-Alpha V1.1

It's finally here!
BPE Pre-Alpha V1.1 and HTTPlugin are done.
I'm tired from programming and testing, so I'm not gonna write much.
Read the readme if you want more.

Find HTTPlugin and the latest version of BPE on the Downloads page.
get BPE Pre-Alpha V1.1 here.

I'm gonna spend any upcoming spare time to write tutorials and update the wiki.

Changelog:
 - changed updateWindowHook
 - added socket ID system
   - updated sendPacketHook
   - updated recievePacketHook
 - added forceRecieveHook
 - added forceSendHook
 - added forceCloseHook
 - added socketOpenHook
 - added socketCloseHook
 - removed PEPAPI V1 support, mostly
 - attempted to make work on Linux and Mac (untested)
 - GUI improvements
   - added "Server Options" window
   - added "Plugin Options" window (incomplete)
   - added "Port Options" window (incomplete)
 - fixed bugs
   - possibly fixed the "multiple hooked servers" bug? (not sure how, might be black magic. the bug should theoretically still be there, but tests indicate it's fixed)
   - fixed problem with data not being sent when a connection was still being fowarded
   - misc other bugs

If I get a Mac tester, I'll try and get Linux and Mac support into the next release.

Packet Editor Progress #6

Things are going well towards the release. probably only about a week remaining.
I have some pretty heavy stuff going on in my life right now, so progress will probably slow down. however, HTTPlugin is working almost perfectly. just one or two small features to implement and then I'll release it with BPE Pre-Alpha V1.1.
Here's a pretty pic of HTTPlugin:

It can redirect HTTP requests to any location (online or offline). it has many uses, one of which being working as a more advanced version of my sitelocked game loader.
Hopefully I can get BPE running on Linux and Mac before the release...

Packet Editor Progress #5

So, it's been a few weeks. I'm starting to get near the next release. about time, too.
Fixing the multiple server hooks bug may have to be postponed, but I've added many more hooks which should hopefully be operational by the next release. Currently, all the plugin hooks are:
(Current, PEPAPI v1)
updateWindow (Called by the plugin, changes window width, height and title)
sendPacketHook (Called by the Core, every time the client sends a packet, allows viewing and modification of the sent data)
recievePacketHook (Called by the Core, called every time the client receives a packet, allows viewing and modification of the received data)
finishPluginSetup (Called by the Core, called after the plugin has been set up, when it is safe for it to start using hooks)
(New, PEPAPI v1.1)
forceRecieveHook (Called by the plugin, allows the plugin to force the client to receive data, crafts a packet sent to the client)
forceSendHook (Called by the plugin, allows the plugin to force the client to send data, crafts a packet sent to the server)
forceCloseHook (Called by the plugin, forces a socket to close)
socketOpenHook (Called by the Core, called every time a socket is opened)
socketCloseHook (Called by the Core, called every time a socket is closed)

Several old PEPAPI v1 hooks will be changed to use the new SocketID system. all hooks are currently in flux, and may very well be drastically changed several times over the next few releases.

Oh, and there's a Wiki now:
http://bpe.wikia.com/wiki/Bmanatee%27s_Packet_Editor_Wiki

Hopefully, I'll do some work on the wiki after this next release, since there should be enough hooks now to make some useful plugins.


Also, if there are any Linux or Mac users who would like to become testers, please contact me.

*edit*
today's one of those days where everything works.
Fixed a dozen bugs. Got my HTTPlugin proof-of-concept working. looks like I'm almost ready for the next release (although, I'd prefer to finish HTTPlugin first, so that there's some example code for the new hooks).

Packet Editor Progress #4 and other things

It's been nearly a month since my last post, so I thought I'd update you all on my progress.
Things have been slow. I've had stuff on. Should be getting some time soon, though.
I'm thinking I'll get multiple server hooks operating then release the next version.
ETA: 1 month +- 2 weeks

I've fleshed out some more of the GUI.
I also started setting up PEW support. might take a version or two for it to be released;
I've also planned a few plugins for it, including an HTTP server re-director (making certain directory's on chosen servers redirect elsewhere, including to the local filesystem, I.E. making everything in www.example.com/dir/ redirect to c:\server\).

I've had some issues with modifying it to run on Linux and Mac, but hopefully I can get it going before next release.

In other news, I've been doing more work on 3D stuff. I'd post more about it, but I'm too short on time. I'm hoping to get my FPS running on a Commodore 64. That should still be within it's limits. I've never written anything for a C64 before... so that'll be interesting.

Also, turns out my "Universal SWF Decryptor" has bugs (I've known about them for a while, but tried to hide them so people didn't exploit them to make "un-decryptable" SWF's) that make it slightly less "Universal". I'll try and fix them when I get a spare moment...


I need more spare time...

Packet Editor Progress #3

Did some more work on it today. Hopefully, I can add Mac and Linux support next release (installing AIR on Linux is a pain in the ass, though).
I just passed the 1,000 line mark for it (1,011 right now, split between 12 classes).

Next release will have various GUI improvements (server options and possibly port options and plugin options windows, adding the ability to remove hooks).
I might fix some of the glitches with having multiple server hooks (currently, all hooked connections are routed to whichever IP is at the top of the list).

I need to add .PEW file loading at some point too, considering that PEW files will make things vastly easier for newbies trying to set up hooks for specific plugins.

I'll probably release some tutorials around the end of this week,

BPE Pre-Alpha V1.0

Here it finally is!
The first public release of my packet editor!

Currently, it comes with no plugins and is windows only, so it will only be useful to those who can program in AS3.
I'm going to be posting tutorials on using and writing plugins for it in the near future, so stay tuned!
In the meantime, you can download the source for a simple Stick Arena Dimensions plugin I made and edit that to work for whatever uses you have.
To use the plugin, hook these servers:
ballistick1.xgenstudios.com
ballistick2.xgenstudios.com
ballistick3.xgenstudios.com
ballistick4.xgenstudios.com
ballistick5.xgenstudios.com
ballistick6.xgenstudios.com
ballistick7.xgenstudios.com
ballistick8.xgenstudios.com
ballistick9.xgenstudios.com  
Or add this to your hosts file:

127.0.0.2 ballistick1.xgenstudios.com #CoreHook IP 67.19.138.234
127.0.0.2 ballistick2.xgenstudios.com #CoreHook IP 67.19.138.235
127.0.0.2 ballistick3.xgenstudios.com #CoreHook IP 67.19.138.236
127.0.0.2 ballistick4.xgenstudios.com #CoreHook IP 74.86.43.8
127.0.0.2 ballistick5.xgenstudios.com #CoreHook IP 74.86.43.9
127.0.0.2 ballistick6.xgenstudios.com #CoreHook IP 74.86.43.10
127.0.0.2 ballistick7.xgenstudios.com #CoreHook IP 74.86.3.220
127.0.0.2 ballistick8.xgenstudios.com #CoreHook IP 74.86.3.221
127.0.0.2 ballistick9.xgenstudios.com #CoreHook IP 74.86.3.222


And hook port 1138.


Currently, you have to manually remove server hooks by editing your hosts file (C:\windows\system32\drivers\etc\hosts).


Anyway, here's the download link for the packet editor.


Current features:
Working plugin system
Working hooking system
Loads previous server hooks when it opens
Probably undetected by most/all current games and anti-cheat systems 

Current known bugs:
Too many to list...


Also: Android has been added to the list of OS's I plan to develop my packet editor for. Support will probably be added for it during Beta.
Linux (and possibly Mac) support will hopefully be added in the next few releases. 

I've also updated the downloads page with BPE and the plugin.

Delays

So, there I was, two or three weeks ago. About to release the first pre-alpha version of my packet editor.
Then I noticed A serious bug. I´m not going to go into too much detail on it, but it basically rendered the packet editor unusable.
After that, I had an insanely busy week filled with assessments, my social life and preparation for the holidays.
And then I flew to tahiti.
I´ve pretty much had no internet acccess here, so I haven´t been able to do any testing and debugging of the packet editor (No internet = no packets).
I get back at the end of this week though, so I´d expect a release around the 22nd this month (2 weeks from now)

In other news, I figured out a new Raycaster-like algorythm that should be between 50 to 100 times faster than the conventional wolfenstein method.
I think I can get it to run in 640x480 smoothly on a 500KHz processor (assuming it can drive the screen). probably even less. I´ll test it on my family´s old Amiga 2000 (about 7MHz) when I can

I´ll probably post some stuff on raycasting and raycasting derivatives soon.

Packet Editor Progress #2

I've been pretty busy this last week or two, but I think It's about time I posted another progress update.
I've been working on the hook, Core API's and plugin integration recently.
I figured out a better way of dealing with multiple servers (and ports) and in the final version, you will be able to hook up to 256 different servers and any number of ports on each server.
I've also fleshed out the plugin file (which will be Packet Editor Plugin files, or .pep files). I'll eventually make a program to quickly and easily make .pep files for plugins. I might post some more details on them soon.
When I get around to implementing it, I'll add Packet Editor Workspace (.pew) files , which will be written in some simple language (currently probably BASIC like) that will be able to do things like:
Unload plugins
Load plugins
Unhook servers
Hook servers
Unhook ports
Hook ports
Change various settings
This will mean that cheats for games can simply be made as one or more plugins and a PEW file so that all the end-user has to do is open the PEW file and use the plugins GUI to select options to use it. they wouldn't need to know how to use the packet editor at all. Hell, they wouldn't even need to know what a "packet" is.
Also, I installed Ubuntu on my laptop's second HDD so, the Linux version's priority has increased a bit. expect a Linux release at the same time (or before) the Mac release (probably about a month from now).

Here's a pretty picture of the current version:

I'll release a pre-alpha version in a couple weeks, probably.
It'll only be useful to programmers as it won't come with the analyzer or manipulator/filterer/editor plugins (which I haven't even started making yet), but you will be able to make and release your own.
And for those who care about open source stuff, all the plugins I make for it (including the anazyer and the manipuator) will be open source. the Core won't be, but I probably won't encrypt or obfuscate it. So, if you're desperate for the source you will probably be able to decompile it. But everyone knows that's not cool.

I think I was gonna say some other stuff, but it's getting late and I've forgotten. I might edit this if/when I remember.

14/6/12
Core: 60% - Core GUI: 70%, Core API: 50%, Core Hook: 70%
Plugins: 18% - Plugin integration: 70%, Packet Analyzer Plugin: 0%, Packet Manipulator Plugin: 0%

Packet Editor Progress #1

So, I've spent the last couple weeks working on my packet analyzer/manipulator, hence why it's been so long since the last update here.
Here's an update on the packet analyzer/manipulator's progress:

All the Core's GUI's components are pretty much done. I decided to program the GUI from scratch and have everything be drawn dynamically, so all the graphics are drawn using AS.

I'm going to add options that allow you to change setting on a per-socket basis (for if you have more than one socket connected to it at a time)

The Core GUI's far from finished, but here's a sneak preview of the current system:

Plugins are SWF's (there'll be a custom file type for them when I get around to it containing important information like which functions to hook, which Core variables it needs access to, title, ect) so are easy and quick to program. Each plugin will run within it's own window and by default will not be able to access other plugins.

Plugins will by default be able to do the following:
Change their window size, change their window title, have their flash code do whatever they want within their window.
Manipulate incoming/outgoing packets
Send packets and simulate receiving  packets

Things that will probably require extra permissions for plugins are:
Adding servers and ports to the "hooked servers/ports" list
Stop other plugins having access to specific packets (i.e stopping another plugin editing a packet it doesn't want it to edit)
Changing run order of plugins
Loading other plugins
Changing other plugins settings
Accessing/overriding other plugins

I might add more stuff in the future, but that's how I see it now.

The socket hook it uses will be cross-platform (However, Linux uses an outdated version of AIR, so a Linux version might not happen but I can confirm is possible) and works by hooking individual servers/ports. And since it's AIR and plugins are written in flash, it's 100% cross-platform allowing the Core and all plugins to work on Windows, Mac and Linux (when I get around to it), making it one of the few (if not only?) cross-platform packet analyzer/manipulators. But the hook does have some downsides.

To take a look at the hook objectively:
Pros:
Cross-platform (Windows, Mac, Linux)
Easy to program
Harder for anti-hack/cheat programs to detect as it doesn't involve modifying programs to hook sockets
Not many (if any) anti-hack/cheat programs check for this specific type of hook
No need to piss around with "socket ID's"
Cons:
Still possible to detect
Works per-server instead of per-program, so can pick up unwanted connections from other programs trying to access the hooked server
Also works per-port and any connections to unhooked ports on the hooked server will be dropped/time out.


I'm expecting the first release to come out in about a month from now.

here's the gist of my progress including percentage completes:
3/6/12
Core: 30% - Core GUI: 60%, Core API: 30%, Core Hook: 30%
Plugins: 15% - Plugin integration: 60%, Packet Analyzer Plugin: 0%, Packet Manipulator Plugin: 0%

Sitelocked SWF Loader

I just finished my SWF sitelock tool for loading sitelocked swfs offline.
This project is the precursor to the packet editor I'm going to make (vast quantities of this projects code can be recycled into my packet editor).
This loader should be able to load ~95% of sitelocked games. it has one or two limitations though:

It's currently windows only (I might make a linux option in the future. wouldn't be too hard. mac would be possible too).
Generally speaking, it can only load games held in a single .swf file. and it tends to break multiplayer games. Both of those are fixable, but it's probably not worth the effort.

Anyways, here's how you use it:

if for example, you wanted to load a sitelocked swf  offline from www.example.com/folder/test.swf you would set "Server" to "www.example.com"  and "Path" to "/folder/test.swf"
after you've set that up, just drag-and-drop the swf onto the loader to load it.

Note: most games only need to be loaded from the correct server and you can usually leave Path blank.

Here's a picture of me loading an unmodified, sitelocked Stick RPG Complete while not connected to the internet:

Note that Path doesn't actually have to be set to anything, I just did that to show it worked.

Download my SWF Sitelock Tool here:
Download

Also, it's an AIR application, so you need AIR installed to run it.

The Future

So, what are my planned projects for the near-future, you ask?
Well, here's the projects I'm working on or about to start:

An AIR-Based SWF loader that can load any sitelocked game from anywhere (i.e. able to play sitelocked games offline)
More pseudo-3d/raycasting
An AIR-Based packet editor. It seems pretty much all packet editors these days are shitty and outdated.

The SWF loader should be out soonish.
Maybe I'll post some of my pseudo-3d stuff I've been doing if enough of my 0 followers want me to.

Universal SWF Decrypter

I made a Universal SWF Decrypter based on the method/code I posted the other day.
you can find the windows binary here or on my downloads page.
It should work on all swf encryptions that use an AS3 loader. which means it should work on ALL mochicrypt games. and probably on all other SWF encryptions, too.

*edit*
Go Here for the new Universal SWF Decryptor V3

Decrypting AS3 SWF's

Today, I found a massive flaw in Mochicrypt and probably all AS3 encryption methods. I'm sure others already know about it, but I'll post it anyway.
Firstly, let me start by explaining how these encryptions work:
The swf is encrypted and stored (generally in the decryptor/loader).
The encrypted swf is decrypted and turned into a byteArray
The decrypted byteArray is loaded using the Loader.loadBytes() method.
The Loader is added to the stage.

and, as it turns out, getting the unencrypted swf from the loader is incredibly easy.
there's this usefull as3 class called "LoaderInfo" that will solve all our problems.
in fact, Loader.contentLoaderInfo.bytes contains the byteArray for the loaded swf.
so, what we can do is load the decrypter, scan the stage's children for Loader objects, find the one for the decrypted swf and dump it's data.

Here's a working example I made for Bloons TD 5:

 package   
 {  
     import flash.display.*;  
     import flash.net.*;  
     import flash.events.*;  
     public class BTD5Decryptor extends MovieClip  
     {  
         private var ldr:Loader = new Loader();  
         private var swf:Object;  
         public function BTD5Decryptor()  
         {  
             ldr.load(new URLRequest("btd5.swf"));  
             ldr.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);  
             addChild(ldr);  
             stage.addEventListener(KeyboardEvent.KEY_DOWN, doKeys);  
         }  
         private function onComplete(evt:Event):void  
         {  
             var ldrInfo:LoaderInfo = evt.target as LoaderInfo;  
             swf = ldrInfo.content;  
         }  
         private function doKeys(e:KeyboardEvent)  
         {  
             if (e.keyCode == 96)  
             {  
                 var file:FileReference = new FileReference();  
                 file.save((swf.getChildAt(1) as Loader).contentLoaderInfo.bytes,"unencrypted.swf");  
             }  
         }  
     }  
 }  

To use it, place the Bloons TD 5 swf in it's folder (make sure it's called "btd5.swf"), open the decrypter, wait for the game to load and then press numpad 0 to save the decrypted swf.

Here's a link to the compiled version of the decrypter (same as the code above):
http://www.mediafire.com/?lfk94ox5ge9i85k

Also note that the above code and decrypter may work on more/all mochicrypt swfs/loaders. I've only tested it on Bloons TD 5's mochicrypt loader as that's what it's made for, but it may very well work on all mochicrypt loaders.
*edit*
it only works on some, not all. I'll release a universal SWF decrypter I've made later today.

Getting around SecurityError #2070

So, today I started playing with some SWF loading code in Flash Builder, and I ran into a common sandbox problem.
You get Error #2070 when a loaded swf in another directory tries to access the stage.
I couldn't get around it by using Security.allowDomain("*") either, because it was an AIR application.
So, to get around this problem I decided instead of directly loading the file using Loader.load() I'd load it by loading the file into a byteArray and useing Loader.loadBytes() instead. and guess what? it works.
It completely gets around the sandbox issue.
Have some code:

 private function loadSwfFromUrl(url:String):void{  
      var context:LoaderContext = new LoaderContext(false, ApplicationDomain.currentDomain);  
      var ldr:Loader = new Loader();  
      var swf:ByteArray = new ByteArray();  
      var fs:FileStream = new FileStream();  
      fs.open(new File(url), FileMode.READ);  
      fs.readBytes(swf);  
      fs.close();  
      context.allowCodeImport = true;  
      ldr.loadBytes(swf,context);  
      stage.addChild(ldr);  
 }  

There's probably a better, simpler way to get around this sandbox issue, but at least this works.

Universal Flash Variable Scanner

So, I had an idea for a universal swf variable scanner.
one that works on AVM1 (AS1/AS2) and AVM2 (AS3) swf's.

The main problem you face when attempting to create such a thing is that AVM1 swf's and AVM2 swf's have separate sandboxes.
AVM2 loaders CAN get and set variables in loaded AVM2 swf's.
AVM2 loaders CANNOT get and set variables in loaded AVM1 swf's.
However, there are ways to get around this.

You could theoretically make a universal scanner made up of an AVM2 loader and scanner and an AVM1 loader and scanner.

for scanning AVM2 swf's there is no problem:
AVM2 Master swf loads AVM2 movie and scans it.

But for AVM1 swf's, you have to get around sandbox issues.
My idea works like so:
AVM2 Master swf loads AVM1 Scanner.
AVM1 Scanner loads AVM1 movie.
AVM1 Scanner communicates with AVM2 Master swf using LocalConnection.
AVM1 Scanner scans AVM1 movie.

If you were smart, you could probably remove the need for communication between the AVM1 and AVM2 scanner parts and have them functioning pretty much completely independantly.

Thought I'd revamp this sack-o-crap and start anew.

I need a place to post all my crap no one cares about anyway.