*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
It’s all possible, and more!
How does it work
PreloadSWF is a feature mostly used by the Flex Profiler. When a profiling start, the Flex Profiler will write its own PreloadSWF entry in the mm.cfg file and launch its sampler SWF. When the sampler SWF is loader, it passes information about the profiled SWF to the profiler via socket connection.
Ok, but what is the relation between the sampler app and the profiled app? Both file are supposedly in separated domains and hence are not supposed to have direct communication one with the other. When the PreloadSWF starts, you have aboslutly no information conserning the other swf being loaded and you have nothing to hook on to get that access (for now).
First, you need the Flash Player debug version
You have to setup you mm.cfg file to point to a SWF.
Then ANY (as3) flash app you load will load your SWF first.
(By the way, when I say any… it’s really ANY! (Mode: debug OR release!)
And it’s also valid in any context: Stand alone Player, Browser, Bridge, ActiveX, anything.
At this point you can add stuff to your stage and actually see it in a public flash app on the internet.
But since there is no communication between the public SWF and your SWF, and your SWF is local to your computer, there is not much to do.
Here come the Magic: Another hidden feature of flash.
When the second flash app is loaded, there is an (undocumented) event triggered called “allComplete“. And the good thing about this event is that it has a valid target! And guess what target this is? The Main flash app! The only thing you have to do is add an event listener on “allComplete” and wait for it to be triggered!
Ok so what can be done with that?
Well, by having access to the Main stage, you can do anything you want! Add sprite, manipulate DisplayList…
You can also have the Flash params because since you got the stage, you also have:
Wow that’s awesome!
But let’s think about it: if I’m loaded first, and I have access to the stage, then what restrain me from calling an external profiler like DeMonsterDebugger?
Again, no restriction here!
Just add the MonsterDebugger classes to you SWF, and run your favorite video from a live website; you can now edit all the interfaces and controlof that flash instance right away!
Using that you can also call public function with parameters inside MonsterDebugger.
But what more could be done…
Class merging? Wrong… you can’t because securityDomains won’t let you.
And what would happen if you take the loaderInfo.bytes, and do a
loader.loadBytes(bytes, Application.currentDomain);
Well that is working, you can now override classes! (But it’s kind of useless since after that your URL won’t be the same and most transactions will be refused after that.
Still it’s a nice trick 
If you’re interested in fake SWF loading with class merge, read my advanced flash player security walkthrough!
Don’t forget that once you modified the mm.cfg file to run your SWF, all flash will run your code, so make sure it’s lightweight!
Example
I made a simple app to show statistic on the currently played flash app.
The objective was to have all the most important information while still keep the smallest interfaces possible.
The profiling information I showed are:
FPS (Frame per Second) with a graph
Current Memory and Max Memory with a graph
Connectivity with MonsterDebugger (The Icon is in color when the connection is established)
The memory graph reflect changes over time.
The app also add a contextMenu item “Show Profiler” which toggle on/off the profiler visibility
open your mm.cfg and set PreloadSWF=c:\MicroProfiler.swf
Enjoy the (profiled) web!
SVN Source Code
Direct View Source
bin/MicroProfiler.swf
Request
The app I made is very experimental and the code is very messy. If someone wants to add feature or make it better please do! Just send it back to me so that I can update it here. Thanks!
Conclusion
I hope that this feature will be used more for “good” reason than for bad ones.
I know that it enables people to manipulate live data and that it can be very tricky, but I really think that better and bigger tools will comes out of all the hidden features I released yet.
I also think that releasing all these information is good for ActionScript because it encourage senior programmer from many other languages to look at as3 and flash in a different way.
Link to my new twitter: @jpauclair
*Edit*
I entered a bug in the Adobe bug base to fix this issue. (But since it’s under Security, no one can see it)
The way I see it: The could block all PreloadSWF action when the loaded SWF is in release mode.
Also, if you want to prevent being targeted by this, follow good coding practice:
If something does not NEED to be public, set it to protected or private. (won’t be seen in MonsterDebugger)
Do not read data like Sprite.x, Sprite.y, just write to them. All manipulation should be done in a background DataStructure.
*End edit*
References
De MonsterDebugger
DisplayLoader
Sampler Package
