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.