Welcome!

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!

Join Today!

Massive problems with my hotel since the new Flash Player Update yesterday

Experienced Elementalist
Joined
Sep 19, 2010
Messages
210
Reaction score
74
Hey, since the new update from Adobe Flash Player (the one that ends with .140) we're having massive problems with our hotel. We're still using the old version (r63a) and refusing to switch to the new one for several reasons, but when you enter rooms or have specific furnis in the room or catalogue, the client freezes and you get kicked out. We're not the only hotel that is fighting with that problem and we've been desperately searching for a solution for hours. Also, we're almost sure that there's a problem with the habbo.swf because we get the error message: TypeError: Error #1009 Cannot access a property or method of a null object reference. It would be nice if anyone could help.

I've two crash logs of Flash Player (enter room and open some furni categories in the catalogue):

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at com.sulake.habbo.room::RoomEngine/-HZ()
at com.sulake.habbo.room::RoomEngine/-3FD()
at -11q::-fc/-3-F()
at -11q::-fc/reset()
at -11q::-fc/dispose()
at com.sulake.habbo.catalog::HabboCatalog/dispose()
at com.sulake.core.runtime::-0jP/dispose()
at com.sulake.core.runtime::-2R5/dispose()
at com.sulake.core.runtime::-2R5/error()
at com.sulake.core.runtime::-2R5/-0MQ()
at com.sulake.core.runtime::-2R5/-20T()

and

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at com.sulake.habbo.avatar::HabboAvatarEditorManager/close()
at -34U::-1dd/dispose()
at -bI::-0eQ/dispose()
at -0gI::-02H/dispose()
at com.sulake.habbo.ui::-20r/dispose()
at com.sulake.habbo.ui::RoomUI/dispose()
at com.sulake.core.runtime::-0jP/dispose()
at com.sulake.core.runtime::-2R5/dispose()
at com.sulake.core.runtime::-2R5/error()
at com.sulake.core.runtime::-2R5/-0MQ()
at com.sulake.core.runtime::-2R5/-20T()
 
Last edited:
Initiate Mage
Joined
Jun 5, 2007
Messages
26
Reaction score
3
You really think that will work? I mean REALLY work? nah
I don't think, I know that's what the problem was for us, RevivalRP and BlissRP. Having looked into the arrow.swf more it seems to have had a different compression type to what all the normal habbo furni has. I imagine it's the same problem with other custom furni.
 
Upvote 0
Joined
Aug 10, 2011
Messages
7,401
Reaction score
3,299
with the browser works correctly

Perhaps its running an older version of flash, which is something you definitly don't want as it could expose you to vulnerabilities and security issues.

I don't think, I know that's what the problem was for us, RevivalRP and BlissRP. Having looked into the arrow.swf more it seems to have had a different compression type to what all the normal habbo furni has. I imagine it's the same problem with other custom furni.

Sounds like LZMA compression isn't handled correctly. Use the decompress SWF tool and see if that fixes anything (Decompress NOT decompile). Really doubt its something in the XML itself.
 
Upvote 0
RaGEZONE VIP
[VIP] Member
Joined
Aug 13, 2014
Messages
121
Reaction score
239
Could someone post a client swf that is having these problems. I want to compare it against the newer client builds and see if they've changed anything in their logic that wouldn't have been affected by this recent patch since then.

Although it does seem like custom assets(clothing/furniture) are the culprit, I'd still like to see if the client can be modified in a way where it won't break when it tries to load them. It would also be nice if one of you runs a server with just one custom asset enabled that is breaking the hotel, so I can have a place to experiment on. (I've no idea how to setup my own hotel)
 
Upvote 0
Joined
Aug 10, 2011
Messages
7,401
Reaction score
3,299
Could someone post a client swf that is having these problems. I want to compare it against the newer client builds and see if they've changed anything in their logic that wouldn't have been affected by this recent patch since then.

Although it does seem like custom assets(clothing/furniture) are the culprit, I'd still like to see if the client can be modified in a way where it won't break when it tries to load them. It would also be nice if one of you runs a server with just one custom asset enabled that is breaking the hotel, so I can have a place to experiment on. (I've no idea how to setup my own hotel)

To me it sounds compression related. I recall someone had issues with custom furniture that were compressed using LZMA.
 
Upvote 0
Junior Spellweaver
Joined
Oct 23, 2011
Messages
112
Reaction score
25
Hey everyone!

I have no clue if this could help anyone out there but here are the changes of the live-hotel.biz habbo.swf file.
The owners don't want to share their fix and so I'll give u the changes. But unfortunately that's not all - the client is still freezing.
In my opinion it's wrong to not share any fix.

Changes (left: before | right: after):







Message to live owners - formerly Imagician:
Please consider your decision and let us know if you change your mind.

And by the way: The guy who did the fix would definitely share his work with everyone. steffchef
 
Last edited:
Upvote 0
Initiate Mage
Joined
May 10, 2011
Messages
36
Reaction score
3
The compression of the pictures are the problem.
You have to decompile and compile every SWF file, that is causing the freeze
 
Upvote 0
RaGEZONE VIP
[VIP] Member
Joined
Aug 13, 2014
Messages
121
Reaction score
239
I think the problem lies with the FileLength property of the SWF file not matching up correctly with where it should end(EndTag). I was looking at the files provided by viacancer, and the "broken" swf "finishes" prematurely before it could get to the required "EndTag". Perhaps in previous flash versions it would simply read until and EndTag was found, but now with the new update it may only allow itself to read within the given FileLength range.

If this is the case, you can fix the files by adjusting the 4Bytes(uint, Little-Endian) at the 4th index position of the swf to it's actual uncompressed size. I hope...

Day 2
I was looking through a couple more broken swf samples and they all seem to have the same problem as described above. I'll try to explain better of what I think the problem is, and I say "think" because I sadly have no environment where I could test this hypothesis.

You must first understand that there are 8 uncompressed bytes at the start of any SWF file that contains the CompressionKind(3Bytes), Version(1Byte), and finally FileLength(4Bytes, uint). The FileLength property is the total amount of space the file will take in bytes on disk, and that is including the first 8 bytes of the file(FileLength includes itself into the total).

Another thing you must know is that every SWF file must end with.. a EndTag. This tag should always be present, and should always be at the point in which the file ends(minus the bytes the tag header takes to describe it). This is where the problem seems to start, all the "broken" assets seem to have its' EndTag located well after it reaches the FileLength position.

Example:
Actual Uncompressed File Size = 60
FileLength = 50 | Supposedly, the SWF thinks the uncompressed file size is 50 bytes.
EndTag.Position = 55 | Tag is located at index #55 of the file.

Ok, but why can it still be loaded through flash decompilers no problem, as well as other browsers?
I believe most of the decompilers, and previous flash versions wouldn't limit themselves by the SWF's FileLength property, and just kept trying to read tags until a EndTag object is found. I don't really know if this is actually the problem yet, but I did make a tool for others to try out on their assets.

I've added the application below as an attachment, and it also comes with the source code. You'll need .NET Framework 4.7.1 to run this. It takes a file directory(not a single file, but a folder) input, and attempts to re-assemble every .swf file it finds if their FileLength property is incorrect.

Warning This application does not create any backups, and modifies the initial file.

Day 3
The FileLength thing I talked about wasn't actually the problem, but a side effect my assembler came up with when 'correcting' the DefineBitsLossless2 tags in the SWF. I've updated the attachment to better target what I think is actually the problem.
 

Attachments

You must be registered for see attachments list
Last edited:
Upvote 0
Joined
Feb 18, 2013
Messages
19
Reaction score
0
Example:
Actual Uncompressed File Size = 60
FileLength = 50 | Supposedly, the SWF thinks the uncompressed file size is 50 bytes.
EndTag.Position = 55 | Tag is located at index #55 of the file.

GOD! I tested it and it worked perfectly! my hotel does not freeze anymore
thanks :d

EDIT: Some mobis give erros and no correction is made, the errors said:


obs:
 
Last edited:
Upvote 0
RaGEZONE VIP
[VIP] Member
Joined
Aug 13, 2014
Messages
121
Reaction score
239
GOD! I tested it and it worked perfectly! my hotel does not freeze anymore
thanks :d

EDIT: Some mobis give erros and no correction is made, the errors said:


obs:
Can you post some furnis that throw this error, would like to take a look later
 
Upvote 0
RaGEZONE VIP
[VIP] Member
Joined
Aug 13, 2014
Messages
121
Reaction score
239
ok, the mobis:
Unfortunately, it seems that these assets are corrupted. Not even Jpexs can disassemble the files:
lidxZhH - Massive problems with my hotel since the new Flash Player Update yesterday - RaGEZONE Forums


Are these the original files prior to running the tool?
 

Attachments

You must be registered for see attachments list
Upvote 0
Experienced Elementalist
Joined
Sep 19, 2010
Messages
210
Reaction score
74
I think the problem lies with the FileLength property of the SWF file not matching up correctly with where it should end(EndTag). I was looking at the files provided by viacancer, and the "broken" swf "finishes" prematurely before it could get to the required "EndTag". Perhaps in previous flash versions it would simply read until and EndTag was found, but now with the new update it may only allow itself to read within the given FileLength range.

If this is the case, you can fix the files by adjusting the 4Bytes(uint, Little-Endian) at the 4th index position of the swf to it's actual uncompressed size. I hope...

Day 2
I was looking through a couple more broken swf samples and they all seem to have the same problem as described above. I'll try to explain better of what I think the problem is, and I say "think" because I sadly have no environment where I could test this hypothesis.

You must first understand that there are 8 uncompressed bytes at the start of any SWF file that contains the CompressionKind(3Bytes), Version(1Byte), and finally FileLength(4Bytes, uint). The FileLength property is the total amount of space the file will take in bytes on disk, and that is including the first 8 bytes of the file(FileLength includes itself into the total).

Another thing you must know is that every SWF file must end with.. a EndTag. This tag should always be present, and should always be at the point in which the file ends(minus the bytes the tag header takes to describe it). This is where the problem seems to start, all the "broken" assets seem to have its' EndTag located well after it reaches the FileLength position.

Example:
Actual Uncompressed File Size = 60
FileLength = 50 | Supposedly, the SWF thinks the uncompressed file size is 50 bytes.
EndTag.Position = 55 | Tag is located at index #55 of the file.


I believe most of the decompilers, and previous flash versions wouldn't limit themselves by the SWF's FileLength property, and just kept trying to read tags until a EndTag object is found. I don't really know if this is actually the problem yet, but I did make a tool for others to try out on their assets.

I've added the application below as an attachment, and it also comes with the source code. You'll need .NET Framework 4.7.1 to run this. It takes a file directory(not a single file, but a folder) input, and attempts to re-assemble every .swf file it finds if their FileLength property is incorrect.

Warning This application does not create any backups, and modifies the initial file.

I do not think that this program is the solution for the problem. For example, the file treasure16_pillow (without graphics tags, for R63A) does not work after running your tool (the hotel is still freezing).
 
Upvote 0
Back
Top