Girls do flash

There aren't so many ladies in IT. There are even less female flashers. At least I don't know of any.

Romanians of our level of education are not misogynists, so I think the main reason why men cover almost 99% percent of the industry is the perception of IT, which is, "purely technical".

Yet we are fortunate enough to have two young Flash ladies in the immediate future. Because we train them. And I'm quite confident about them.

Now, why do I write about it only now? It struck me when I was looking for a partner, for a dance course I began today. After all my friends had to say no to me (either they can't meet the schedule, or I'm too ugly), I asked around the company w/o much hope. And guess what: I get myself a dance partner! And one that knows a bit of Flash! Awesome! I think you know what we're gonna talk about at the studio.

No, it's not Flash!

God, why is my blog read only by geeks?!?

Planning in Flash

Flash "industry" is plagued by poor programmers. Main causes:
1. Real programmers don't know what Flash is offering now (especially concerning ActionScript3).
2. Current "flashers" are mostly graphic designers forced to learn some AS in order to enhance their sites, presentations and eventually make simple games.

There are lots of awful practices like including code into the graphics file (.fla) and such only because Flash allows it. Flash was meant from the beginning to be easy on non programmers and thus permissive. Worse than Visual Basic.


One good practice used everywhere else but not so much in Flash is planning the application's technical architecture. What are the advantages of this?

1. You have a clear idea of what the app should do and how does it do it.
2. It's easier to scale and modify.
3. It generates all the code, leaving you to write only the code inside methods
4. Makes it easier for new programmers to join the team at a later point in development.
5. Easier to trace and debug.

Although at first it seems overkill, you'll soon see that it's a must for apps larger than 20 classes.

I personally prefer Visio for my diagrams (C# data models), but you can use any tool according to your style and needs. See a list here.

Check this for the things you need to have in your UML tool.

Hacking in Flash. Part two

I'll discuss here hacking into socket apps. It doesn't really require Flash to do it, but the stakes are higher here, usually significant money are involved.

Hack 1: Get an account into the system
Vulnerability: Weak overall security model.
Method: Sniff the data passed on connection. Or adapt the hack described here for socket.

If the connection is not crypted and they usually are not, you can intercept everything on it. Just look for the tools to do that.

Protection against hack: There are various methods here:
1. Exchange credentials via https. Then use an authentication key for every future message. Unfortunately this alone is not sufficient as you will see on hack 2 bellow.
2. Use an encrypted connection. Flash Media Server supports this feature. I don't recommend implementing your own encryption, since the benefits are too small and security increase not that significant.


Hack 2: Hijack an existing connection
Vulnerability: Weak overall security model.
Method: You'll need to control a network node for this. Replace the original client (the client end of the connection) with your own.

Socket connections are not that continuous as they seem. The hijack won't be detected by both server and client unless some tricks are developed especially for this. The hijacker can be a half proxy, half illegitimate app. Can bypass basic checks like unique auth keys per message. You just have to decompile the original client and use the code sequence to encrypt the keys.

Protection against hack: SSH mixed with unique auth keys per message will make hacker's life so hard he will probably quit. Also implement intrusion detection for both client and server. Most probably the client will be completely blocked for paralel distress connections, the hacker simulating a network failure, but the server can implement a policy for this.

Hacking in Flash. Part one

A lot of software companies develop Flash based applications w/ serious security issues.

This part will review hacking methods for server-side scripts, while the second will delve into socket methods.

Tools you need:
1. Data transfer sniffer.
This will help you discover the protocol used by communication. Browser sniffer (IE, FF), network sniffer, whatever works. I recommend to search one that will describe data structures used. Usually for GET and simple POST transfers you can manage w/o, but for AMF, it's better you have one.
2. Decompiler
This will allow you to see the AS code used by the original Flash component of the application. This will also help you get the protocol. In the course of hacking, you will replace the original Flash with your own or you can use them both side by side.

Hack 1: Get an account in the system
Vulnerability: Weak security model on the server.
Method: apply brute force to discover passwords. This can be used to simple HTML forms too (PHP, ASP, Perl, it doesn't matter).

You'll need some dictionary files for this and possibly a names file. This files usually store one value per line. Just search for some on the Internet. Then you need to find the data structure. For HTML forms, just read the HTML source code, use the decompiler for SWF files. Make an algorithm to cycle through names and passwords. Check the auth failure response and implement a test that will take notice of successful attempts. Show the right values in a textfield or use some other method to store them.
If you have a lot of time, make an algorithm that will compose passwords from ground up. 1, 2, 3, 4 letter combinations will run pretty quick, depending on your connection. For 5, 6 letters and more, expect to wait serveral hours, days, and so on :) Basic optimisation: first make only lower letters combinations. Then capital. Then numbers. Then lower and capital. Then lower and numbers. You get the idea.

Protection against hack: Simple. Just block the account for that IP, class or everything for 10 minutes after detection of 3 auth failures. This will make even 3 letter passwords very hard to catch. If you detect more than 3 auth in 3 seconds or more than 60 per hour, then block that IP for 1 month. Good job, mr. Programmer :)


Hack 2: Access data beyond your rightful area in apps where you already have an account. Trick timed tests. Forge scores in games.
Vulnerability: Weak security model on the server.
Method: determine the Flash part to deliver false data.
Step1. Because you need to be authenticated when you're making calls to the server, just authenticate w/ the original app and open a new tab in browser. Auth sessions are browser based and not tab/window based, therefore you can run operations from another tab and the server will see you as authenticated.
Step2. Send the fake data. For GET and simple POST you don't even need Flash. Now you can take 15 minutes tests in any time period you want, you can send scores to your liking. If the server delivers information by id, just use other ids than the ones offered to your account until you find what you need.

Protection against hack: Don't believe everything the client (Flash) says. If it's about time, make your own verifications. If it requests a resource, verify the client's right to that one.


I know systems where the client is requested to deliver user id, company id and such at each call. How stupid is that?

There are other methods of breaking into Flash apps, but those are not involving Flash directly so I won't go into them. Next we'll discuss hacking on Flash using sockets.

Developing in Flash

Here are some major steps once the specs are established with the client. Stuff here is applicable to every client/server devel context, not only Flash.


1. Making the technical specs. The specs included in the contract and the specs for the devel team are not the same. Same spirit, different form.

2. Making the app architecture starting with the client interface, then client logic, client objects, client/server comm, data objects, server logic, databases.
This paradigm of client over server is quite young, only 10 years of so, before that was common to start with database design and make your way through to user interface. This is still the modus operandi in some companies.

3. There are various development styles, two approaches that I like are cascade cycles and extreme programming. However these are applicable only on large apps. Every module should be tested using unit testing before committing into repository.

4. Testing.


What I really wanted to talk about is the client/server interface. Once at this phase, an API - Application Programming Interface - should be worked out between the client and server teams. If the approach is thin client/heavy server, the data structures most convenient to the client should have priority.

If the server load must be minimal, as often the case with small hardware budgets, costs migrate to the client. This includes for processing power, connections to other services, etc. Nowadays, when the costs for server clusters are quite affordable, and everyone seeks a broader customer base, I think thin client/heavy server is the way to go.

Although I worked server-side a few years ago (C# and Oracle) and liked it, currently I work client side only. Every part has its own advantages. server side has its heavy algorithmic thrills (data structuring, data processing, optimizing) while client side has the ergonomics, - the part that makes the human experience enjoyable -, and availability. Through connectivity you can deploy a client everywhere: mainframes, desktops, laptops, pdas, mobile phones. Flash included. Would you have considered remoting on a phone a few years ago?

Up until now my apps had a server connector that could be replaced at any time with another for another type of server. These connectors must be clever enough to handle synchronous (server-side scripts, LocalConnection, ExternalInterface) and asynchronous comm (socket), and still implementing a comfortable API with the main module. That is, the main should not care if the comm is synchronous or not.

Furthermore, the main should not care if the server is C, C#, Java, ASP, PHP, Perl or whatever. It should not care about database either, how some token data is named within the database. Having a client/server comm API, you should not rewrite your client when the server side changes something or gets changed altogether.

Should the server change when the client changes? You might know the answer already. It doesn't when the client changes involve only minor data restructuring. However this does not happen often. As changes comes from the customer, the large majority of cases requires server modules being rewritten and sometimes database restructuring.


All this comes from my experience, not from books. It may seem obvious and childish to some, but I know quite a few people who would like to contradict me. You're invited to comment ;)

Big project. AS2 or AS3?

If you start a new project, AS3 is giving you so much. Check this out: http://livedocs.macromedia.com/labs/as3preview/docs/
It finally became a medium where a programmer can feel at home.

My company, Eye Partner, is using almost exclusively AS3 for its projects. This can sound common if we're talking about Flex 2, since the technology is more than half year old now.

Things change a little in the case of Flash 9. F9 is not out and it won't be several months from now. Yet we have a project cumulating several thousands of work hours based on it. While this might seem overkill to some, we just keep working, cornering bugs, solving instability issues and getting the product done. If Flex would've been an option, we would've taken it, but the level of visual customization required is too great.

Our approach is to have a main core which loads external modules as needed. Modules are swfs that can be written either in F9 or in Fx2. Because yes, programming in Fx it's much more clean and straightforward. It's charted territory after all. Sometimes it's just easier to use F8 for some modules, especially for people who are not yet proficient w/ F9.

Now the interesting part: you can't really use F8 for these modules, right? AS2 and AS3 (more accurately VM1 and VM2) cannot talk to each other. Here is what livedocs say:

ActionScript 3.0 code can load a SWF file written in ActionScript 1.0 or 2.0, but it cannot access the SWF file's variables and functions.

So, what do you have left: LocalConnection, NetConnection. Jeez, what options :)

Turns out that some guy Robert Taylor has figured it out. His solution facilitates communication between F9 and F8 SWF files via ExternalInterface. Check it out: http://osflash.org/flashinterface

We most probably will continue the path we've taken at the start, but surely there are some huge applications out there that simply cannot be rewritten in a month or two. And continuing w/ AS2 for every new module could mean suicide in the long run.

Building the ultimate flash video/audio player

I know the title it's pretentious. But I got you to read this, didn't I?

The goal is to make a decent feature complete flv/mp3 player in Flash 9. Why there isn't one already? Basically, because the Flash Player doesn't take advantage of DirectX (or any significant video acceleration) and it isn't a viable solution for good quality, full screen viewing. There are video players for web and some desktop players as an aid to developers. Also some savvy users use them for whatever flvs they got from youtube and such.

Why do I want to make one? Well, I'm a geek. And it's not that hard either. Before getting to work, let's put some specs together:


A. General features:
0. Formats played: flash video (Sorenson Spark and On2 VP6 codec), MP3
1. Streaming, progressive download
2. Dynamic buffering (adaptive, "intelligent")
3. Skinning (of course)
4. Smoothing, deblocking both adaptive and set by user
5. User settings stored on local computer (also history saving)
6. Playlist
7. Zoom options: 50%, 100%, 200%, to fit, full screen
8. Format accomodation (if you have a 4:3 or 16:9 TV and the image coming from cable or DVD player is the other format, then you have some options like: 14:3, zoom, inteligent)
9. Side notes support (those are encoded as metadata directly into the flv)
10. Subtitle support (sub, srt, xml)
11. Multiple selectable audio tracks (yeah, the sync job...)
12. Media properties: original fps, current fps, codecs, everything meta
13. Key binding (configurable)
space, p, click - play/resume
left key - back 10 seconds
right key - forward 10 seconds
ctrl+left - back 1 frame
ctrl+right - forward 1 frame
up key - volume up 10%, maybe logarithmic at some point
down key - volume down 10%
page up - forward 10 minutes
page down - back 10 minutes
ctrl+` - zoom 50%
ctrl+1 - zoom 100%
ctrl+2 - zoom 200%
ctrl+enter, f - toggle fullscreen
ctrl+s - toggle mute
o - toggle OSD
v - toggle subtitles
.... and the list goes on ...
14. Recording video/audio (needs FMS/FCS/Red5/etc.) This opens a whole new branch of features.
15. Plug-ins to insert the player into different CMSs.

B. Things I need feedback on:
1. Automated detection of blank frames (or any other color) in order to skip the part or just to accurately trigger thumbnail generation
2. Fake streaming. No FMS needed, just some preprocessing and a small script (PHP let's say). This has the advantages of both worlds: near instant seeking and, at the same time, caching.
3. User notes on timeline, also saved locally.
4. Extensions support. This is kind of crazy...
5. Desktop implementation
6. Other supported formats: swf, jpg, gif, png (boring...)
7. Uploading: do you see any real advantage to that?
8. Zooming, scan & pan (keeping display area fixed)

C. Things I don't know yet how to do, if even possible:
1. Slow/fast motion

D. What other feature would you want? If it's useful, I'm obsessed enough to do it. Please comment and help me gather the specs for a great player.

Some references:
1. Jeroen Wijering player - embedding type, I really like it
2. Martijn de Visser player - desktop type

PS: Will I share the sources? I never once protected my work or refused to share knowledge. Nor does it have to be me the only author. So basically yes, unless the company asks me to do this at work and then decide not to share.

Profit Sharing Program

I think we're the only firm in Iasi doing this. In this loyalty program, you get company shares every six months. Also a percentage of each project's sales is given to the team assigned.

There are limits to these shares, regarding selling and keeping. Still, this is a sound way to motivate and involve people.

In US this is an old concept in large and mid size companies, but here and everywhere in Eastern Europe it is still a novelty. I'll come back to the subject in a few months describing the measurable effects. People working twice as hard maybe? :) Or mass burnout...

AS3 Training

Yes, we actually train three young people in Flash 9 and Flex 2. Due to company's strategy of fast expansion, we need every flasher we can get. Since they aren't that many in the city, we're taking students and fresh graduates and preparing them for their first job. Me likes it :)

It's basically a three months crash course into all major areas of Flash programming. Four trainers are involved in this, allotting 3 to 5 hours a day. The rest until 7, are for the trainees to study and work on small projects.

The programe is listed here. After a week, I think we're doing good. We might've been a tad too optimistic in our plans regarding the amount of knowledge we could inject into these newbies. So, we're dropping PHP & MySQL teaching and also security and hacking. Too bad, I really wanted to do that.

Depending on this session's success, we'll be starting a new one in the summer. So, if you're good at OOP, willing to learn some exciting multimedia technology and confortable w/ working in Iasi, by all means, apply!

An old belief of mine just got reinforced: college doesn't prepare you for the labor market. Not here in Romania, where most teachers concerns are to feed some theoretical data to students and pick up a modest paycheck twice a month.

Eye Partner

Actually, my experience on it.

When I first joined the company, there were 14 employees including me, of which 4 were flashers (flash programmers). Now, after 4 months, we are 11 flashers and flash apprentices from a total of 25. The trend is set to continue. Now, this is growth!

Working here is quite enjoyable. On my first weeks I've learned a bit of Flex 2 from Kidu (photo bottom left). That served me well, as I never actually worked on a Flex project before. He's probably the most helpful guy around. Thanks, Kidu!

Management is quite relaxed, despite our daily reports. It's not really bothering as it can be in other companies. They say that IT has the mildest managers, this is certainly true at Eye Partner.

We're located some half kilometer from Tudor, the main student campus here, so it takes a few minutes on foot to get to the Tudor mall where we usually take our lunch break.

The building itself is more of a homey office, warm lit as you can see on the photos bellow.

Of course, not all is milk and honey, but overall is great working here and I doubt that is much left for improvement.

Intro

Basically this blog is about AS3 (both Flash & Flex) and Eye Partner, the company I currently work for.

About me. I'm a Flash programmer for several years now, Flash 4 beeing my debut. I was interested in visual programming since high school and I later found Flash to be the most satisfying medium to my needs of processing and distributing multimedia content.

Eye Partner is a company located in Iasi, Romania, aiming to be one of the world's leaders in this field: multimedia distribution by means of Flash and Flex as front ends. At least this is what my boss says :)

This blog is partly supported by the company, in an attempt to become more widely known. Their condition is for me to write at least three times a week, so check back often :)