0

I have just inherited a project that uses SecureSWF. I am trying to utilize RobotLegs (which uses SwiftSuspenders for reflection to implement dependency injection) and have just discovered that SecureSWF breaks the build. Has anyone had a similar problem? Is there a workaround? Is it possible to obscure a SWF that's built with RobotLegs at all?

alecmce
  • 1,456
  • 10
  • 23
  • Tough one. You might want to get directly in touch with Till Schneidereit at http://swiftsuspenders.org/ to find out if the byte code magic used in SwiftSuspenders and SecureSWF have any way of tolerating each other. My guess, though, is that you won't have much luck. :( If you have to make a decision, I'd go with RobotLegs. If the project is even just a bit complex, decompilation won't be much use for anyone - the time needed to figure out how the code works is not worth the effort. – weltraumpirat Jul 18 '12 at 21:07
  • Thanks weltraumpirat. As it happens I know Till and the guys building RobotLegs. There were a lot of helpful suggestions on their google group: http://bit.ly/MKEFBZ – alecmce Jul 19 '12 at 17:19

1 Answers1

0

It's straightforward, actually. You need NAMES for reflection. And they are the primary target for ANY kind of obfuscation and mangling. Since we absolutely can not abuse the verify mechanism in flash player VM (which is damn good), we have no way in getting around it.

I'm using secureSWF too, and I have a mechanism of sewing skins and controllers together with descrybeType() and a hell of a lot of checking of types and members. I exclude my sensitive to obfuscation classes from the protection workflow. They are of no use to a hacker anyway.

Michael Antipin
  • 3,522
  • 17
  • 32