4 ms·

Ask HN: Flex/Flash, Authenticating your .swf + decompiling

9 points by arjunlall 18y ago

In a nutshell, we are developing a web app where our app and flex fontend need to share data securely. The problem is that our application server needs to know that the requests we are getting from our flex application are not spoofed. Right now we essentially have a secret key that is hashed with request data to authenticate the flex app. Problem is, how do we keep the secret key in the flex app code without someone able to snag it by decompiling? I can think of a million ways to obscure the key into the code, but that only will delay a break in, not stop it. It seems impossible for there to be any secure cryptographic system if an intruder can see the source. Is there any good way to actually secure flex from getting decompiled? From what I have seen everything just obscures code.

hashtable 18y ago
Um, isn't this the same problem as DRM? (which we all know cannot be solved.) The fact is, if my computer can execute the code and make the request, so can I. The only thing you can do is to try to mitigate the risk or make it more difficult.
- arjunlall 18y ago
  Yes, same problem. Bummer... Has anyone had success with making flash decompiling more difficult? Anyone used http://www.amayeta.com/ http://www.amayeta.com/ ?
  - sratner 18y ago
    My instinct would be: don't bother. If the data you are protecting is worth enough to someone, they will decompile it anyway.
e1ven 18y ago
Unfortunately, there really isn't a way to do this- One of the fundamental rules in security training is never trust the client. Anything you can write, they can open. For the most part, it won't even be that hard. Don't waste time obfuscating it.. If it's at all possible, time would be better spent redesigning the infrastructure such that the client never has any data that you don't want the user to have.. The best way to do this is to generalize an API that the backend uses to talk to the front end. Then, modify your client to use this. We do this with Chron X- We have a generic Card game API that we call from our Client.. It's not perfect, but we're actively making design decisions assuming that someday, other clients may connect, with or without our consent and blessing. We may never allow it, but we have to work under the mindset that the hackers can do anything our Flex can. I'd suggest writing a middleware layer, which takes in requests based on a sessionID, and then allows only certain commands to go through, and only certain data to come back. That way, you minimize your exposure.
wmf 18y ago
Newer versions of Flash Player and FMS include remote attestation aka SWF verification; AFAIK it hasn't been cracked yet (but it hasn't been reverse-engineered by Red5 either). http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_configtasks_22.html#1223759 http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_confi...
ars 18y ago
You're authenticating the client? Not the person? That's impossible to do.
fatjonny 18y ago
If you can trust the client by having them enter in a password, can't you then set up a system that uses the same idea as public-key cryptography (http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography)? Once the user has logged in and authenticated with their password they generate their public and private keys and send the server the public key while keeping the private key local. This method would be processor intensive, but good security usually isn't cheap. Or maybe my understanding of how public-key cryptography works isn't accurate and someone can explain why it wouldn't work?
- wmf 18y ago
  Here's the attack: The user writes software which performs the same authentication handshake as the official client, but after the handshake it starts sending evil messages to the server.
  - fatjonny 18y ago
    Isn't that where the password comes into play? Basically you authenticate once by passing the password and the client generated public key to the server. The server checks the password and then if it matches it sends all future communication to the client encrypted with their public key. It can generate a new "public" (in quotes because it will only be shared with the client) key specifically for that client and send it encrypted to the client using the public key passed along with the password. All communication from client to server will be decrypted with the private key that matches the public key given to the authenticated client, and all communication from server to client will be decrypted with the private key that matches the public key the client gave to the server with the password. This is probably more like TLS or SSL (http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/Transport_Layer_Security) than I suppose. Which makes me think you could just use an SSL connection since it is supported (http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001356.html http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/...). Or am I really missing something and should just stop commenting? :)
    - 18y ago
jm4 18y ago
Hmm... The fact that you're so concerned about requests not hitting your web app without going through your Flex front end raises a red flag... Anyway, you can obscure the key into the code all you want. If it's a string value there's only one place it will ever be when the .swf is decompiled and that's in the constant pool. If it's a number value stored in a variable or even a few concatenated strings it might be a little more difficult since it's not going to come out and slap somebody in the face, but to say it's trivial to retrieve the key would be the understatement of the decade. Before going this route it might be a good idea to decompile some .swf files to see what it looks like. Check out a program called Describe SWF and take a look at the documentation for Flasm. Lots of good info there. There's no good way to secure your Flash/Flex code so it's not worth the effort to even entertain the thought. I develop a bot with a custom Flash player and I'm just amazed out how many people do stuff like this. The best advice I can give you is that anything you put in a Flash file is there for the taking as if you were advertising on your home page. Bad idea.

9 points by arjunlall 18y ago

hashtable 18y ago

Um, isn't this the same problem as DRM? (which we all know cannot be solved.) The fact is, if my computer can execute the code and make the request, so can I. The only thing you can do is to try to mitigate the risk or make it more difficult.

arjunlall 18y ago
Yes, same problem. Bummer... Has anyone had success with making flash decompiling more difficult? Anyone used http://www.amayeta.com/ http://www.amayeta.com/ ?
- sratner 18y ago
  My instinct would be: don't bother. If the data you are protecting is worth enough to someone, they will decompile it anyway.

e1ven 18y ago

Unfortunately, there really isn't a way to do this- One of the fundamental rules in security training is never trust the client. Anything you can write, they can open. For the most part, it won't even be that hard. Don't waste time obfuscating it.. If it's at all possible, time would be better spent redesigning the infrastructure such that the client never has any data that you don't want the user to have.. The best way to do this is to generalize an API that the backend uses to talk to the front end. Then, modify your client to use this. We do this with Chron X- We have a generic Card game API that we call from our Client.. It's not perfect, but we're actively making design decisions assuming that someday, other clients may connect, with or without our consent and blessing. We may never allow it, but we have to work under the mindset that the hackers can do anything our Flex can. I'd suggest writing a middleware layer, which takes in requests based on a sessionID, and then allows only certain commands to go through, and only certain data to come back. That way, you minimize your exposure.

wmf 18y ago

Newer versions of Flash Player and FMS include remote attestation aka SWF verification; AFAIK it hasn't been cracked yet (but it hasn't been reverse-engineered by Red5 either). http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_configtasks_22.html#1223759 http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_confi...

ars 18y ago

You're authenticating the client? Not the person? That's impossible to do.

fatjonny 18y ago

If you can trust the client by having them enter in a password, can't you then set up a system that uses the same idea as public-key cryptography (http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography)? Once the user has logged in and authenticated with their password they generate their public and private keys and send the server the public key while keeping the private key local. This method would be processor intensive, but good security usually isn't cheap. Or maybe my understanding of how public-key cryptography works isn't accurate and someone can explain why it wouldn't work?

wmf 18y ago
Here's the attack: The user writes software which performs the same authentication handshake as the official client, but after the handshake it starts sending evil messages to the server.
- fatjonny 18y ago
  Isn't that where the password comes into play? Basically you authenticate once by passing the password and the client generated public key to the server. The server checks the password and then if it matches it sends all future communication to the client encrypted with their public key. It can generate a new "public" (in quotes because it will only be shared with the client) key specifically for that client and send it encrypted to the client using the public key passed along with the password. All communication from client to server will be decrypted with the private key that matches the public key given to the authenticated client, and all communication from server to client will be decrypted with the private key that matches the public key the client gave to the server with the password. This is probably more like TLS or SSL (http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/Transport_Layer_Security) than I suppose. Which makes me think you could just use an SSL connection since it is supported (http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001356.html http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/...). Or am I really missing something and should just stop commenting? :)
  - 18y ago

jm4 18y ago

Hmm... The fact that you're so concerned about requests not hitting your web app without going through your Flex front end raises a red flag... Anyway, you can obscure the key into the code all you want. If it's a string value there's only one place it will ever be when the .swf is decompiled and that's in the constant pool. If it's a number value stored in a variable or even a few concatenated strings it might be a little more difficult since it's not going to come out and slap somebody in the face, but to say it's trivial to retrieve the key would be the understatement of the decade. Before going this route it might be a good idea to decompile some .swf files to see what it looks like. Check out a program called Describe SWF and take a look at the documentation for Flasm. Lots of good info there. There's no good way to secure your Flash/Flex code so it's not worth the effort to even entertain the thought. I develop a bot with a custom Flash player and I'm just amazed out how many people do stuff like this. The best advice I can give you is that anything you put in a Flash file is there for the taking as if you were advertising on your home page. Bad idea.