My Flash 9 Workflow
Just recently I’ve tested a number of web applications that made heavy use of Adobe Flash. Considering I didn’t find a whole lot when I was searching I thought I’d document my current workflow.
To be honest I’ve never gone too deep into hacking up SWF files. So, after finding a few bugs in the non-flash areas I decided to invest a bit of time in disassembling and reassembling SWF files.
Most web app folk are at least aware of the flare and flasm tools, the go-to tools featured in the 1st Ed. of Web Application Hacker’s Handbook. These were the tools I knew existed and I attempted to apply them. Unfortunately in my situation these were near useless. Apparently flare and flasm are dead projects and have no roadmap for supporting ActionScript 3. A quick look over at the OWASP Flash Security Project got me in touch with RABCDasm. There are more than a couple disassemblers, but tools supporting reassembly appear limited. This suite did pretty much everything I needed.
I also like using HP’s SWFScan. Not really for the static analysis (your mileage will vary), but for the neatness and ease of a friendly AS3 format.
So, here it is:
- Acquire SWF file
- Run SWFScan on the file
- Follow the RABCDasm usage to the point that you’ve disassembled the .abc files
- grep -i -r these directories for keywords that you’ve located using the more readable AS3 in SWFScan
- Make appropriate changes
- Follow the RABCDasm usage for reassembly
- Start up a python -m SimpleHTTPServer 80 in the reassembled SWF directory
- In Burp, make a proxy replace rule to replace the normal content with your new file
- In Burp, make a proxy replace rule to replace the AllowScriptAccess parameter from “sameDomain” to “always”
Anyway, given this setup it’s not entirely difficult to at least test and attempt to attack things like client-side input validation and controls. That said, learning some ABC is in order as I’m just flapping my fledgling flash flippers.
Comments and suggestions welcome.
