Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!
Sorry, I forgot to add something to the host check thingy bypass stuff, so if you're client is getting stuck on 76% it is not your fault. It's a pain implementing the rest of it, jump instructions are cancer.
Edit:Took a few good hours to figure out a decent way to do this(thanks Burak):
It's not as easily done in bytecode, especially when all the obfuscation is placing retarded jump instructions everywhere. You also can't really update something that's inside of an IF statement so easily, you need to correct the amount of bytes it needs to jump so you need to go back and re-write it from that point if the code inside is bigger/smaller.
I just took the easy route and made it jump +6 bytes, because yea.
Hello,
I know how to update etc. (Finding packets and structures) but i dont know things about the crypto so i have a question:
In the RSA file there are 3 Keys:
NED
in your topic stays 2 Keys, N and E
Hello,
I know how to update etc. (Finding packets and structures) but i dont know things about the crypto so i have a question:
In the RSA file there are 3 Keys:
NED
in your topic stays 2 Keys, N and E
Hello,
I know how to update etc. (Finding packets and structures) but i dont know things about the crypto so i have a question:
In the RSA file there are 3 Keys:
NED
in your topic stays 2 Keys, N and E
The RSA keys in the main post are placed into the client by default, I just now added the private exponent(D) to the main post(I forgot to) for it to be used by the initiator(Using Joopie's keys, since most people are "familiar" with them already). Does anyone want anything else to be added to this application, ideas, suggestions?
Header extractor,
Splash photo changer,
Build string changer(packet)
Message name changer(_-AB > Incoming_4000)
I wouldn't want to start to work on any of this unless people would actually use it.
When the "dumpheaders" argument is set, each message instance will have a hash. This hash could be used to compare previous client build messages, with newer ones, or find similar message types within the current build.
Download:
You must be registered to see links
This feature is still new, and there is still a bit more I can add to make more "unique" message hashes(MD5). I took the idea from XDR's AHPU, since it's a pretty Ducking cool idea. To summarize the brilliant idea, imagine a red flower with 6 petals, but some punk always paints it blue every week. The point is, the flower will still have 6 petals, regardless of the paint.
When the "dumpheaders" argument is set, each message instance will have a hash. This hash could be used to compare previous client build messages, with newer ones, or find similar message types within the current build.
Download:
You must be registered to see links
This feature is still new, and there is still a bit more I can add to make more "unique" message hashes(MD5). I took the idea from XDR's AHPU, since it's a pretty Ducking cool idea. To summarize the brilliant idea, imagine a red flower with 6 petals, but some punk always paints it blue every week. The point is, the flower will still have 6 petals, regardless of the paint.
Xdr is master haha, i really liked his idea of using "points" system to check which packet is the updated packet of the previous.
Is good but not totally 100%. I saw that 99% of the Outgoing packet's are correct, but the major mistakes happens in Incoming packets.
I think because some packets doesn't has really something to compare. For manually help some strings, messages, variables, and non obfuscated strings, also structures, and size of the line helps to the AHPU to check which packet is the right one. But some packets is really hard to compare. Some packets also change the position compared of other packets (generally example packet _-XHD456 will be above _-fhnjbj87 so in newest release the _-44444yeg (the new packet from _-XHD456) will also be above from the new packet from _-fhnjbj87, but some times the packet voids changes, some un-obfuscated methods will be obfuscated.
I'm trying to figure out how is the packet name obfuscation, i think is not random. I thought every release the gamedata file names and also the PRODUCTION, RELEASE, DEVELOPMENT folders from gordon follows a hash. This hash probably is used for a base SALT for the Habbo.swf obfuscation, packet id changes, and also the same in (example: furniture.xml furnitures id's). Some things changes others not. Some packets doesn't change ID too.
Will be funny if they-re using some old ciphers like RSA to obfuscation. If the SWF was in C++ using IL decompiler will be really hopeful.
Also the Void names of the Habbo.swf follows some 64bit-HEX criterias. Soo, someday we will figure out how this xit is encrypted and encoded.
When the "dumpheaders" argument is set, each message instance will have a hash. This hash could be used to compare previous client build messages, with newer ones, or find similar message types within the current build.
Download:
You must be registered to see links
This feature is still new, and there is still a bit more I can add to make more "unique" message hashes(MD5). I took the idea from XDR's AHPU, since it's a pretty Ducking cool idea. To summarize the brilliant idea, imagine a red flower with 6 petals, but some punk always paints it blue every week. The point is, the flower will still have 6 petals, regardless of the paint.
Going to take a minute to explain the process thoroughly, since some of you might want to know without trying to "decipher" the source code(
You must be registered to see links
:
You must be registered to see links
). When choosing the objects to include in the hashing process, you cannot include the object's name for very obvious reasons(name obfuscation). You can include anything else, as long as it's not the "name" of said object.
As many of you know already, each packet is represented by a class/type. With each class/type, comes a set of traits that represents the type's properties/methods/constants/fields. Each trait contains unique data, a method with two parameters, a constant with a specific value, and the method body(bytecode) that contains the instructions to read/write the data of the message. By using these values, we can start generating a unique personality for each message handler. Although, there are many Outgoing message that construct a basic packet the same way, so it becomes harder to create a unique hash for it.
Here are two Outgoing message handlers:
Code:
public class _-1Yy implements _-2kQ, _-2D-
{
private var _-2pd:Array;
public function _-1Yy(_arg1:int, _arg2:int)
{
this._-2pd = new Array();
super();
this._-2pd.push(_arg1);
this._-2pd.push(_arg2);
}
public function _-4bf():Array
{
return (this._-2pd);
}
public function dispose():void
{
this._-2pd = null;
}
public function get disposed():Boolean
{
return (false);
}
}
Code:
public class _-2AS implements _-2kQ, _-2D-
{
private var _-2pd:Array;
public function _-2AS(_arg1:int, _arg2:int)
{
this._-2pd = new Array();
super();
this._-2pd.push(_arg1);
this._-2pd.push(_arg2);
}
public function _-4bf():Array
{
return (this._-2pd);
}
public function dispose():void
{
this._-2pd = null;
}
public function get disposed():Boolean
{
return (false);
}
}
Disregarding their names, they will both generate the exact same hash.
A good way(possibly the only way) to combat this problem, is to scan each method body that sends packets and check if this instance/type is called in the bytecode. Once it has been determined if it is being used by the method, add the instance that houses the method to the hashing process.
Fortunately, every Incoming packet handler is a bit more unique compared to that of the Outgoing composers. The "uniqueness" does not come from the type that is connected to the id, but from the Parser type that it uses.
This is a basic Incoming packet event handler:
Code:
public class _-260 extends _-1l0 implements _-3GS
{
public function _-260(_arg1:Function)
{
super(_arg1, _-3vs);
}
public function _-67n():_-3vs
{
return ((this._-1uA as _-3vs));
}
}
They all mostly look like this, except for some that have a second parameter in the constructor, but don't worry about that. The parser is "_-3vs", but since we can't use that name for the hashing process, we use that type's inner data to represent it:
Code:
public class _-3vs implements _-3DS
{
private var _-5sT:Array;
public function flush():Boolean
{
this._-5sT = [];
return (true);
}
public function parse(_arg1:_-5gX):Boolean
{
var k:int = _arg1._-1We();
var k:int;
while (k < k)
{
this._-5sT.push(new _-2nE(_arg1));
k++;
};
return (true);
}
public function get prizes():Array
{
return (this._-5sT);
}
}
Look at all that unique stuff, it's so unique I'll name him billy. We can use billy's methods/bytecode/slots to build an identity for him, case closed. Please note that HabBit(1.3.177), currently does not use the Parser for the hashing process, this will be included in the next update but I wan't to include a bit more to it before releasing. I've managed to reduce the amount of Incoming duplicate hashes to 125 out of a total of 468 Incoming message handlers.
Xdr is master haha, i really liked his idea of using "points" system to check which packet is the updated packet of the previous.
Is good but not totally 100%. I saw that 99% of the Outgoing packet's are correct, but the major mistakes happens in Incoming packets.
I think because some packets doesn't has really something to compare. For manually help some strings, messages, variables, and non obfuscated strings, also structures, and size of the line helps to the AHPU to check which packet is the right one. But some packets is really hard to compare. Some packets also change the position compared of other packets (generally example packet _-XHD456 will be above _-fhnjbj87 so in newest release the _-44444yeg (the new packet from _-XHD456) will also be above from the new packet from _-fhnjbj87, but some times the packet voids changes, some un-obfuscated methods will be obfuscated.
I'm trying to figure out how is the packet name obfuscation, i think is not random. I thought every release the gamedata file names and also the PRODUCTION, RELEASE, DEVELOPMENT folders from gordon follows a hash. This hash probably is used for a base SALT for the Habbo.swf obfuscation, packet id changes, and also the same in (example: furniture.xml furnitures id's). Some things changes others not. Some packets doesn't change ID too.
Will be funny if they-re using some old ciphers like RSA to obfuscation. If the SWF was in C++ using IL decompiler will be really hopeful.
Also the Void names of the Habbo.swf follows some 64bit-HEX criterias. Soo, someday we will figure out how this xit is encrypted and encoded.
The header ids are all generated randomly.
The obfuscation is just obfuscation, nothing special about that. I have no idea where you'd get this idea from.
Noce updates, Arachis! Can't wait to see more updates :
Going to take a minute to explain the process thoroughly, since some of you might want to know without trying to "decipher" the source code(
You must be registered to see links
:
You must be registered to see links
). When choosing the objects to include in the hashing process, you cannot include the object's name for very obvious reasons(name obfuscation). You can include anything else, as long as it's not the "name" of said object.
As many of you know already, each packet is represented by a class/type. With each class/type, comes a set of traits that represents the type's properties/methods/constants/fields. Each trait contains unique data, a method with two parameters, a constant with a specific value, and the method body(bytecode) that contains the instructions to read/write the data of the message. By using these values, we can start generating a unique personality for each message handler. Although, there are many Outgoing message that construct a basic packet the same way, so it becomes harder to create a unique hash for it.
Here are two Outgoing message handlers:
Code:
public class _-1Yy implements _-2kQ, _-2D-
{
private var _-2pd:Array;
public function _-1Yy(_arg1:int, _arg2:int)
{
this._-2pd = new Array();
super();
this._-2pd.push(_arg1);
this._-2pd.push(_arg2);
}
public function _-4bf():Array
{
return (this._-2pd);
}
public function dispose():void
{
this._-2pd = null;
}
public function get disposed():Boolean
{
return (false);
}
}
Code:
public class _-2AS implements _-2kQ, _-2D-
{
private var _-2pd:Array;
public function _-2AS(_arg1:int, _arg2:int)
{
this._-2pd = new Array();
super();
this._-2pd.push(_arg1);
this._-2pd.push(_arg2);
}
public function _-4bf():Array
{
return (this._-2pd);
}
public function dispose():void
{
this._-2pd = null;
}
public function get disposed():Boolean
{
return (false);
}
}
Disregarding their names, they will both generate the exact same hash.
A good way(possibly the only way) to combat this problem, is to scan each method body that sends packets and check if this instance/type is called in the bytecode. Once it has been determined if it is being used by the method, add the instance that houses the method to the hashing process.
Fortunately, every Incoming packet handler is a bit more unique compared to that of the Outgoing composers. The "uniqueness" does not come from the type that is connected to the id, but from the Parser type that it uses.
This is a basic Incoming packet event handler:
Code:
public class _-260 extends _-1l0 implements _-3GS
{
public function _-260(_arg1:Function)
{
super(_arg1, _-3vs);
}
public function _-67n():_-3vs
{
return ((this._-1uA as _-3vs));
}
}
They all mostly look like this, except for some that have a second parameter in the constructor, but don't worry about that. The parser is "_-3vs", but since we can't use that name for the hashing process, we use that type's inner data to represent it:
Code:
public class _-3vs implements _-3DS
{
private var _-5sT:Array;
public function flush():Boolean
{
this._-5sT = [];
return (true);
}
public function parse(_arg1:_-5gX):Boolean
{
var k:int = _arg1._-1We();
var k:int;
while (k < k)
{
this._-5sT.push(new _-2nE(_arg1));
k++;
};
return (true);
}
public function get prizes():Array
{
return (this._-5sT);
}
}
Look at all that unique stuff, it's so unique I'll name him billy. We can use billy's methods/bytecode/slots to build an identity for him, case closed. Please note that HabBit(1.3.177), currently does not use the Parser for the hashing process, this will be included in the next update but I wan't to include a bit more to it before releasing. I've managed to reduce the amount of Incoming duplicate hashes to 125 out of a total of 468 Incoming message handlers.
The header ids are all generated randomly.
The obfuscation is just obfuscation, nothing special about that. I have no idea where you'd get this idea from.
Noce updates, Arachis! Can't wait to see more updates :
:
