It's been a while since I gave a progress update on BPE.
IP hooks (in the form of PreHook) are being added next release. unfortunately, for both hooks to work simultaneously, I have to re-design the entire hook system, which is why this release has been taking quite some time.
Since BPE was originally designed to only have one hook system, it makes things difficult because the server hooks and the port hooks were effectively the same body of code, and now need to be completely separated and mostly re-written (I'm splitting one class into about five to make it work).
There will be a "Server Manager" class that acts as an interface for the different hooks (including plugin interaction, which is controlled by the "Plugin Manager"), and a "Master Server" class that will organize the serversockets and pass connections through the different hooks as they come.
So, next release should fix the two most significant limitations of BPE: the multiple server hook bugs and not being able to hook IPs.
PEW files will probably start being implemented in the release after this next one. I'm focusing on fixing major bugs/limitations before adding new features.
And yes, I still need a Mac tester.
I'd also appreciate a Linux tester.
Showing posts with label analyzer. Show all posts
Showing posts with label analyzer. Show all posts
Monday, January 28, 2013
Monday, October 8, 2012
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:
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:
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:
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
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:
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.
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.
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.
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.
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.
Tuesday, September 11, 2012
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...
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:
Hopefully I can get BPE running on Linux and Mac before the release...
Saturday, September 1, 2012
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).
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).
Sunday, August 12, 2012
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...
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...
Wednesday, July 18, 2012
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,
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,
Thursday, June 14, 2012
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%
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%
Sunday, June 3, 2012
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%
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 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%
Subscribe to:
Posts (Atom)