Tag Archive for 'Java'

MXML in AS3 projects and fixing mxmlc

Not many people actually know that you can use MXML in pure AS3 projects. Here’s an example.

Create a new AS3 project, create a new file in package cp. Call it App.mxml. Flex Builder will not allow you to create an MXML component in a pure AS3 project, so you have to do it manually. Here’s my App.mxml.

<?xml version="1.0" encoding="utf-8"?>
<cp:Component xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:cp="cp.*" >
    <cp:Component var1="123"/>
    <cp:Component var1="124111"/>
    <cp:Component />
</cp:Component>

Notice that I’m using my own namespace and no flex components. Now define Component class in cp/Component.as.

package cp {
import flash.display.Sprite;

[DefaultProperty( "children" )]
public class Component extends Sprite {
    public function Component() {
        super();
    }

    private var _children:Array;
    public function get children():Array {
        return this._children;
    }
    public function set children(value:Array):void {
        this._children = value;
        trace( value );
    }

    public var var1:String;
}
}

In main project file I put:

package {
import cp.App;
import flash.display.Sprite;

public class mxml_test extends Sprite {
    public function mxml_test()
    {
        this.addChild( new App() );
    }
}
}

To compile it you need to have framework.swc in library path though. And [DefaultProperty( "children" )] doesn’t work neither in 3.4 SDK nor in 4.0 for some reason. People say it should work in 4.0 but it doesn’t.

That’s weird that Flex SDK 3.4 and Flex SDK 4.0 produce different code from MXML files. 4.0 adds much more useless Flex stuff to resulting SWF. If you want you can add -keep-generated-actionscript compiler parameter to check converted code. Flex 4.0 adds such functions for every object in original MXML.

private function _App_Component2_i() : cp.Component {
    var temp : cp.Component = new cp.Component();
    temp.var1 = "123";
    _App_Component2 = temp;
    mx.binding.BindingManager.executeBindings(this, "_App_Component2", _App_Component2);
    return temp;
}

I don’t like that executeBindings thing in my code and useless mx.* classes it puts in SWF making it 3.5Kb in size. So I decided to patch Flex SDK since it’s kind of open source. Flex SDK SVN can be found at opensource.adobe.com/svn/opensource/flex/ and it contains everything you should need to rebuild your own version of SDK. These links helped me a lot too, and thanks God I found those Eclipse projects inside after trying to resolve libraries issues for an hour.

There are only 2 places where I found this executeBindings stuff, both classes are in flex2.compiler.mxml.gen package. I commented this code and compiled mxmlc.jar. I’ve been doing it all evening but couldn’t get rid of it. I can’t get why. I am totally sure that new mxmlc.jar is used but this stupid string is there anyway.

I consider the final result to be a failure but at least I now know that you can patch Flex SDK as you wish. But I didn’t have time to try to understand how the whole compiler code works and where it handles bindings exactly. I didn’t find much on the internet so I guess not many people actually tried to build their own versions of compiler.

Desperation, we know what it is…

I didn’t know it was THAT hard to find a good AS3 developer in Russia. Looks like wherever you go you’ll meet a couple of people who know Flash. But their skill level is very low.

This post tells us how desperate some companies are. They are offering professional Java or C# programmers to learn AS3 and work for them.

Running native processes in AIR2

Here is an example of using new AIR2 feature which allows you to run system native processes from your application. The guy uses a Java tool to grab screen images.

This might not be that exciting, but Java as AIR runs everywhere and this method allows you to basically use Java libraries in your Flash project. I need to parse PDF files for my needs and I am pretty much desperate on this one. But using Java might be a way out. There are plenty of libraries.

Flex UI and some Java logic should be good.

Flash flaw puts most sites, users at risk…

… says computerworld.com.

This wouldn’t be funny if it was 100% true. I found this link (and this link) at a Russian IT community where the majority of people doesn’t really like Flash. So if they see “flash” and “flaw” in a topic title they usually behave like Pavlov’s dogs. I saw a lot of comments that Flash sucks, that it’s good time to install flash-blocking plugins and start using Silverlight or Java. But it seems nobody really knows what is going on.

  1. This is actually not a bug
  2. This is not a Flash specific flaw
  3. This is a really old vulnerability

But nooo, people keep running around screaming and cursing Flash.

This is so funny reading you guys. You don’t know much about the subject but keep making weird conclusions. During his or her life a person once understands that “you sleep better if you know less” (there should be an English proverb like that). If you are saying that this is a “fundamental flash bug” you might not know that it is not even a tip of an iceberg.

If you spend half a day googling and reading books you might find out that danger is actually everywhere, you just don’t know about it assuming that all hardware and software is flawless. Well, this “flash” vulnerability is just one in the huge family of Cross-site Scripting vulnerabilities. There were a lot of them found and a lot of them are still hiding within your favorite browsers. Everything executed on client side is vulnerable to XSS attacks. The most common technology is JavaScript, almost every other attack involves JavaScript too, like using it to retrieve sensitive data from Flash, Java or Silverlight.

So, how does it work? An XSS attack is done using a vulnerability in client software which allows an attacker to inject malicious code into client’s trusted zone and execute it. Security system thinks that if this code is executed from example.com it is trusted and can have access to all data associated with this domain.

How is this related to Flash? This is related to Flash as much as it is to every other client-side technology, computerworld just took one and started blaming it. So, I somehow upload my SWF to example.com. If it allows me to upload SWFs of course. If it doesn’t I can either rename it to something else or join with something else, apparently Flash Player can load a file of any extension placed in src attribute of embed tag. Anyway, if this SWF goes into /uploads folder of example.com it is considered to be trusted, because someone long time ago assumed that if a file is within public access of a domain it could be uploaded there only by that domain’s admin, which is not usually true as we see. This SWF now has access to everything related to example.com via JavaScript. This would be really stupid to display it without allowscriptaccess=never on example.com itself. But the article above says that this SWF is loaded with an external link not from example.com. For example, someone pretending to be your friend John sends you a link which points to this SWF being loaded from example.com where you are logged in right now. Congratulations, the SWF just stole your cookie.

If I’m not mistaken, this vulnerability can be easily fixed if user uploaded content is kept on a separate subdomain.

This is not related just to Flash. As you see a lot of JavaScript is involved. And you definitely can do the same using Java. But what’s more, as I said there are ways to bypass server’s uploading restrictions. For example, it’s possible to combine GIF and JAR (it’s actually a ZIP file) or PDF and JAR into one file so it looks like a perfect GIF (PDF) and can be executed as a perfect JAR. Did you know that? Did you know that there are still a lot of vulnerabilities in your favorite browsers? I don’t even want to mention HUGE number of sites made by newbies which have absolutely no security, they allow SQL injections and XSS JavaScript Injections. And you trust them your private information and credit card numbers? Did you know that it’s even possible to trick Google and find out your password? Did you know that saved passwords in Firefox can be retrieved by hackers too?

Did you know that these are not even 1/10 of all vulnerabilities? But why have nobody hacked you yet? Probably someone already did, you just don’t know that. Or nobody is interested in you.

How is this related to Flash? This is not Adobe’s fault. Of course they can come up with something involving crossdomain.xml and even more restrictive policies, but you can just upload your own crossdomain.xml to example.com as you did with your SWF. This is not again Adobe’s flaw. This is probably because in the beginning of Internet all basic protocols were not designed with security in mind. And now people invented new ones and upgraded old ones fixing leaks here and there.

Sites owners must develop their projects with security in mind and not just blame Flash. This is stupid.

And the last one. I actually USED this vulnerability long-long time ago against one of Flash discussion boards. Once again, this is not new!