Community Expert

Question

SWF Encryption and Security by kglad

Forum|Forum|19 years ago
February 12, 2007
35 replies
15163 views

i have developed a swf encryption program (jsfl) that, i believe, is relatively uncrackable. relatively means if it were worth tens of thousands of dollars to crack, it wouldn't take more than a few weeks for a professional to crack.

it does have two weaknesses. one i'd rather not reveal but has nothing to do with the encryption scheme, the swf or anything else under the control of the encryption scheme. and the other is the possibility someone could hold a gun to the head of the encrypter and demand the code. (which i think would be a pretty successful tactic.)

but other than that it is much more secure than anything else i've seen.

i've uploaded a test file to my website. i'd like to invite users to decompile, check the source code or otherwise mess with it to see if they can find a weakness.

there's no need to crack the code and spend a lot of time. i'm just looking to see if someone can see a method to attack the encryption that would eventually lead to success.

http://www.gladstien.com/test.html

p.s. the swf displays a much faster and much more versatile (than g skinner's) hit detection scheme that i made after working on a project for urami. click on the dot or weird shape to drag. release and the object released turns green if it has a positive hit with the other shape.

p.p.s. please don't hack my server. i'm not challenging anyone to destroy all my files or otherwise bring down my website. i'm just looking for challenges to the encryption scheme.

ActionScript

This topic has been closed for replies.

Show previous replies

G

ggshow

Participating Frequently

lets put a gun on kglad's head and say:"hand up,what is the k1k2k3k4??"

kglad

Author

Community Expert

yes. but that's the problem. you need k1,k2,k3 and k4. or a work-around.

G

ggshow

Participating Frequently

load variable from keygen.pl
return k1,k2,k3,k4 as argument for function asDecF(),

if we can get this 4 value, we can run it without keygen.pl

am i right?

still trying...

kglad

Author

Community Expert

individual bits of actionscript are encrypted as strings prior to compilation. the encrypted code is then compiled.

when the swf is run the encrypted code is decrypted into executable actionscript. the encrypted code is clearly inspectable in the swf upon decompilation as is the decryption algorithm.

i cannot imagine that inspection of that code even by an experienced actionscripter that knows what the swf does would give any hint of what code was used.

in the example file, i did not include any red herrings or honey pots or other things that would put additional blocks or delays in the way of someone trying to decrypt the actionscript. i didn't not write superfluous code. i started with a file that i used to create a shape-based hit detection scheme with several advantages over gskinner's hit detection method. i executed my jsfl file targeting the hit detection file and encrypted it, saved as test.fla and published test.html and test.swf.

the link above should be working now. it's working for me.

but because i'm the creator of the perl script and because i gave myself permissions that i didn't give other users it was working for me before i left for work and then failed for me (and others) because none of us were recognized as the file creators. i have now given everyone full permissions (777) for that perl script.

N

Newsgroup_User

Inspiring

> doesn't work for me either. lol.
> i made a last minute change to the swf after i posted this message and
> failed to retest. i'll have to fix it later today when i get home.

Is it ready to look at yet ??

N

Newsgroup_User

Inspiring

I mean in the sense that it is strings in the compiled script that are
obfuscated, rather than the whole compiled script.

kglad

Author

Community Expert

it's obsfuscation in the same sense that all encryption is obsfuscation. that is, you start with something like a credit card number (or an onPress statement), you change it to something else so if the something else is viewed it's difficult to determine the credit card number (or that an onPress statement was used).

http://www.gladstien.com/test.html should be working now. i needed to change permissions on the perl file.

N

Newsgroup_User

Inspiring

So it is basically obfuscation then?

kglad

Author

Community Expert

no, you're correct on both counts: the one part i didn't want to reveal (and am now revealing) is that the contents of one file located somewhere (accessible by the swf) need to be kept secret.

the fact there is such a file is no longer secret. that file is a perl file but can be written in any server-side executable language and stored on any server that has a cross-domain policy that allows the swf to execute it.

that file checks if it's being called from the expected file (in my case, gladstien.com/test.swf) and if it is, it returns the keys to decrypt the code which, because of flash limitations is restricted to numbers with 60 digits. that's not secure enough for financial transactions but for a swf, it's enough for now.

in my case that file is keygen.pl at www.gladstien.com/cgi-bin/keygen.pl. can you find the contents of that file? that's the weakness. i put some blocks in the path of discovering that's the file used but those last minute changes caused the problem with the swf not executing. i'll fix that when i get back home.

as for the TEA weakness, i've substantially strengthened it. the number of possible codes have been dramatically increased. in fact, encoding the same string many thousands of times is very very unlikely to return the same encryption twice.

so the question is can you view the contents or the return values from keygen.pl?

R

Rothrock

Inspiring

kglad – there are only two things that I would be worried about. The first one be the one thing you would rather not reveal. I'm only an amateur crypto guy, but isn't it generally considered that any scheme that relies on keeping part of the process secret won't stay secret for long. Assuming of course that the value of the info is non-trivial compared to the effort to find out the secret.

The other would be TEA itself. I seem to recall there was some weakness with it? I mean isn't it possible to do a related-key attack with 2^23 chosen plaintexts? Nothing fatal and probably good enough for this purpose. (I'm just teasin' you a bit on that last part. I suppose you know a lot more about this than I.)

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded