Security Question...

[Buffman]

Is there a way or possibility of someone reverse engineering a compiled AMS application?

I'm writing some crypto functions in my application and including some salted password functions, and I want to make sure that someone can't discover my salting method...

Once its compiled, can I rest assured that someone can't reverse engineer my app?

[Josué Alba]

I think your code is safe under AMS but let's see what the experts says

[bule]

As safe as 20+ letters password protected zip file, AFAIK.

[Lorne]

When you're talking about computers, safety is always a relative term.

Technically, anything that runs on a current PC can be reverse engineered. At some point the code and data gets into memory, and a skilled hacker could retrieve it from there.

What kind of information are you trying to protect?

A good way of handling password validation is to store only the MD5 digests for the valid passwords, and compare that to an MD5 digest of what the user enters. If the MD5 hashes match, the passwords match...with no need to store the passwords at all, and no (feasible) way to determine the passwords from the list of MD5 hashes.

[Buffman]

Normally I use MD5 digests, but in this case I need to store the user's password somewhere and call it within the application without a user prompt. Similar to a "remember my password" feature.

My approach is something like this:

- User enters password for the first time
- Encrypt the user's password with a salting function (password+salt)
- Store the encrytped hash in the registry
- The application, with the salting function stored in the code can decrypt and user the user's password automatically.

I realize that storing passwords is not the securest method, but I'm thinking a blowfish encrypted salted string would be fairly secure and protect against dictionary attacks.

The only thing I'm slightly concerned about is whether someone would be able to determine what 'salt' i'm using from going through my binary...

[Lorne]

Hmmm...it's possible. The Lua script is stored plain-text, which is encrypted for delivery but is obviously decrypted at run time. It would probably be possible to intercept the script before it gets compiled into byte code for the interpreter.

If you're concerned about someone gaining access to the Lua script, you could move this functionality into a DLL function and call that. It could still be reverse-engineered by a good hacker but you could put some anti-debugging hoops in if you wanted.

If you wanted to keep it in Lua, but wanted more control over the protection of the script (i.e. something different than the Zip password protection that is used by default), you could put the actual encryption code into a separate text file, and blowfish encrypt that. Then read that file into a string and decrypt it in memory (so no decrypted file exists on the hard drive) and use a core Lua function named loadstring to execute it.

Here's an example to show how loadstring works:

--loadstring(string [, chunkname])

-- calling loadstring compiles the string (without running it) and returns a function
-- it returns nil if there were errors compiling it
-- (note: you could read the text in from a text file, get it from a web script, etc.)
local myfunc = loadstring("Dialog.Message(\"Title\", \"Text\");");

if myfunc then
	-- call the compiled function that we loaded
	myfunc();
end

Application.Exit();

The code could still be caught by a hacker with good memory sniffing skills, of course, but it wouldn't be retrievable from the autoplay.exe even if you got past the zip protection.

[Buffman]

Ahhh thanks Lorne!

This is exactly what I was looking for! I think your method(s) will suffice for security concerns.

Thanks for the great info and providing the sample code!

[Intrigued]

Without thinking on it to long, this offering I did may help in some way, if needed:

http://www.indigorose.com/forums/sho...ory+encryption

[Buffman]

Sweet!

I'll definitely check it out!

Thanks!