Skip to content

Flash Preload Profiler

In the last few weeks I started to use more and more the mm.cfg feature « preloadSWF »
This enables you to start a SWF before any SWF launched by FlashPlayer and have much information on the launched SWF. It also enables you to “hook” on the launched SWF and manipulate it’s display list.

I then decided to try making my own profiler for flash in a way that it could be started for any web site without having an interface too invasive. FlashPreloadProfiler is born.

FlashPreloadProfiler is an open source multi-purpose profiler designed to help productivity and stability during development by exposing “under the hood” representation of any flash scene.
The main goal is to help expose and diagnose problems before they get too big.

It enables developers, artists, designer or testers to see what sometimes “cannot be seen” such as:

  • What is the current FPS and memory statistics of a SWF
  • Where are all mouse event listeners objects
  • What is the global scene overdraw
    • How many sprites are contained in the scene and may be one over the others
  • What is the life cycle of all the display objects on the stage
    • Instanciation, AddedToStage, RemovedFromStage, Garbage Collection

    Want to know more?

    Full description and download here!

    *the profiler is on the top-left corner of the application

    Advertisements

    New Flash Visual Profiler

    I frequently use Flex Profiler for my job in order to track slow functions, bad memory usage and other things.

    But when it come to diagnose a problem in a project, it’s often hard to tell what’s going wrong “in the screen”. You can use other live performances analyzer like “Hi-ReS” or even MonsterDebugger… But it’s always detached from what’s in the screen!

    So I decided to make a Visual Profiler that can help diagnose quickly problem with memory allocation, bad assets re-use, and Garbage Collector Overhead.

    *Edit 2010/05/24*
    This post was a pre-release of my tool “Flash Preload Profiler
    If you want something more comlpete: Get it here
    *End edit*

    Read more…

    Flash Assembler (not ByteCode) : And you thought it couldn’t get faster

    In the last posts, I talked about what you can get from mm.cfg setups but I didn’t give any GREAT example of how to use that in an optimization context.
    Well here it is:

    var a:int = 1;
    var b:int = 2;
    b = a + a + a;
    

    How could something this simple could be optimized? Can it?
    Well yes it can! Not 10% faster… 300% faster!
    Read more…

    One SWF to rule them all : The Almighty PreloadSWF

    *EDIT 2010-08-27*
    this tool = @deprecated
    the NEW (and way better) version can be found at: FlashPreloadProfiler
    *END EDIT*

    In my last article I introduced you to a bunch of features hidden in mm.cfg,

    Many were very happy to see advanced tracing and logging features.
    Many were happy to be able to see the byte code easily.
    But everybody missed the most important feature!

    The Almighty PreloadSWF

  • Would you like to have debugging information (fps, memory, etc.) for you flash app?
  • Would you like to have Debugging information for other people flash app?
  • Would you like to be able to see flash var passed to a live SWF?
  • Would you like to be able to edit live flash app on any website?
  • Would you like to be able to retrieve encrypted files that have been loaded in an unencrypted format?
  • It’s all possible, and more!
    Read more…

    AS3 hidden treasure in the mm.cfg file. Revealing and documenting many Flash secrets!

    *Update: 9 dec 2011*
    Using a few of these hidden features, TheMiner let you analyse memory, performances, DisplayList, loaders and a lot more!


    *end update*

    When I found this, I just could not believed it.

    In the past few weeks I did many articles greatly appreciated by the community: FlashPlayer Security, FlashPlayer Memory, AS3 Array under the hood, Optimized Base64 Encoding. But this one, I think, will rule them all!

    I knew for a long time now that flash had undocumented features, little part of flash that could help speed up process (like the memory opcodes) or make interaction easy with right click and that kind of things. But I never thought that FlashPlayer would hide data that could help find bugs, or give better knowledge of how flash is interpreted.

    As you may know, The mm.cfg files is located in:

    • Windows; C:\Documents and Settings\username\mm.cfg
    • OSX; /Library/Application Support/Macromedia/mm.cfg
    • Linux; home/username/mm.cfg

    This file is interpreted when a Flash Player instance launches a SWF and gives indication of what should or shouldn’t be done.
    For example, most people use this file to set tracing parameters:
    ErrorReportingEnable=1
    TraceOutputFileEnable=1
    TraceOutputFileName=c:\logs\flashlogs.txt
    MaxWarnings=50

    Many other options are specified in the Adobe FlashPlayer Admin Guide… but most of is NOT DOCUMENTED!

    There is a LOT of thing to talk about and many cutting edge tools to improve your understanding of flash.

    So let’s get into it
    Read more…

    Reverse engineering AMF3 Vector for Java

    Did you ever worked in AS3 with Byte Array and AMF data serialization for transferring object over network ? It really simplify everything. Of course there is a size overhead. But the bottom line is that we can save hundreds of hours by using it.
    Since Flash 10, there is one big flaw with AMF: it doesn’t support Vector. Well it’s not true, The FlasPlayer support it, but not what link to it. So you still can serialize Vector object in a byte array and save it in a file for example, but you can’t send it to a web page written in php or a server in Java because there is no implementation of those new « flash 10 features (Vector, Dictionary,…)» in the flex framework. The thing you can do is use an Array instead of a vector, and enjoy the conversion in the Java Hash Map server sie. This is done because of the « sparse possibility of the array » (read my Tamarin Array Analysis).

    One more thing: not only it’s not implemented, but it’s not even documented!

    tonight is gonna be a good good night

    I knew that tonight my wife was going to some bar with a friend and that my two kids would be sleeping after 20h00. So I made a bet with my friends at work that I would reverse engineer the Vector serialization in AMF to implement it in the flex messaging framework in Java. And all that before my wife come back at 3h00.

    Well guess what! I made it in only three hours!
    Read more…

    Base64 Optimized as3 lib

    *Edit january 2012*

    A New faster version is available here: http://www.sociodox.com/base64.html

    *End edit*

     

    A few weeks ago I started a personal project that needed to send binary data to a text (not binary) receiver. This couldn’t be done without encoding the binary data in a format accepted by the receiver. There is a few well know encoder: Base64, yEnc, etc.
    Base64 can have a 30% size overhead (compare to yEnc) but it’s fast and easy to use. I chose Base64.

    While searching the net for some Base64 lib in as3, I found the class inside the as3Crypto package, and one from the PHPRPC protocol.

    So I started with those lib. DAMN it was slow.

    So why after a few years of as3 there is still no optimized library for something that common?

    I went through both lib and optimized what I could. The final version is ~700% faster with almost no heap expansion compare to both libs.
    Read more…

    Tamarin part III – Garbage Collector in Flash (10.0)

    I did a lot of very processing intensive application during the last few years. Applications that required both CPU optimization and memory optimization. And I had a LOT of problem with the Garbage Collector of Flash. It was often holding the CPU for too long thus creating visible pause. That kind of behavior was of course unacceptable for real time application. I tried a lot of things in FlashIDE and FlexSDK to optimize what I could but most of that work was based on trial an error or misunderstanding of how GC really worked.

    So I decided to take this one step further on my own time and read the whole Tamarin source.

    When I first started thinking of this article, I had no idea what I was getting into.
    During my first reading of Tamarin a few months ago, I saw some things about a Mark and Sweep Algorithm… Some ZCT algorithm and I thought everything was kind of trivial. No way!

    *everything that I’m going to talk about is based on my own reading of the open-source framework Tamarin and public news from Adobe. I’m not representing Adobe in any way and if my interpretation is bad about anything, please tell me!*

    As you know, Adobe as worked on bringing flash to portable device for some time now and obviously, memory management and performances of flash was kind of an issue for smaller device. In last march Lars Hansen did a GREAT review of what were the actual Issues of the GC and some actions that should be taken to fix theses.

    I also started a discussion recently with Lars about the F10.1 GC . That GC is more focused on small device and less on application that require a LOT of memory. With some test I did the GC was going nuts and taking 1.6Go of memory with visible freeze of a few seconds. I’ll be filling a bug soon, but if F10.1 is released as the official player soon, a lot of games will fail!

    By the way, If anyone have interesting management solution for memory consumed (allocated and freed) by visual assets created on the timeline. Please post your solutions!

    But enough with this… Let’s start!

    Tamarin GC is a mix of:

      1. Conservative collection with incremental Mark/Finalize/Sweep algorithm
      2. Deferred Reference Counting (DRC) with ZeroCountTable (ZCT)

    Read more…

    Tamarin Part I.I – AS3 Array (bug)

    Thanks to the analysis Jackson Dunstan, I was able to find a “bug” in the Array management.

    I did an article about array data structure in AS3 a few days ago, and Jackson did some more test on the array after that.

    From the Tamarin code, I was able to conclude that removing an element from the aray would split it in two parts, a dense array and a HT.

    And with the checkForSparseToDenseConversion function, Tamarin was connecting back spliced parts of the arrays.

    But the thing is: No lower limit for the HT is set when splitting the array in two.

    Here is the ArrayClass bug i submitted to Adobe Bug Base:

    Read more…

    Flash Player Security Advanced Walkthrough

    Using the techniques I’m going to explain, it’s possible to do about anything in any flash application.

    If you have ideas or solutions for some of the techniques, please make a comment!

    Stating the obvious:

    • SWF are easy to decompile to get the ActionScript code.

    Application like “Sothink SWF decompiler” can do that in no time. Next…

    • Browser can cache downloaded SWF to run faster on future access

    IE cache its file under “C:\Documents and Settings\USER\Local Settings\Temporary Internet    Files\Content.IE5  (Windows hide this folder even when you turn everything to be visible. just type it in the address bar).  Next…

    • There is no way of knowing if a SWF as been tampered.

    No signature… No checksum… Next!

    • Client application can never be trusted

    Well, that’s just a fact. Next?

    • File can’t be encrypted (or almost)

    Flash Player must be able to read your files and since it has no idea of what encryption you use, you must “load” a encrypted file, and the algorithm of your encrypted file is in the loader. But what do you do with the loader itself then?

    Things you should be aware of:

    • There is a feature in flash call “ApplicationDomain”.

    The ApplicationDomain class is a container for discrete groups of class definitions. Application domains are used to partition classes that are in the same security domain. They allow multiple definitions of the same class to exist and allow children to reuse parent definitions.

    • Often, the only thing triggering a reload of a SWF from the browser cache is its size. (If the size is not exactly the same, download it again)
    • Flash Player has no way of knowing if a SWF is authentic or not.
    • Browsers have no way of knowing if a SWF is authentic or not.
    • Flash Player doesn’t care if a SWF is filled with null character at the end of the file.

    The SWF contains its size and will be loaded accordingly to that size, but what follows it don’t matter.

    Let’s proceed to a series of iterative “how to” attack and “how to” respond from both attacker and developper side

    Read more…

    %d bloggers like this: