Security Issue Related to Decompilation in LiveCode

[keliko]

I have encountered a serious security issue with LiveCode. The code encryption feature in LiveCode does not adequately protect sensitive strings against decompilation. I can easily read sensitive strings after decompiling using tools like x64dbg.

Steps to Reproduce:

1. Use LiveCode to create an application with sensitive strings (e.g., license checks).

2. Set the password for the stack using LiveCode script:

set the password of this stack to "Password"

on mouseUp
put fld "uuid" into y
put "335bc5eb-c565-4d6a-a394-151acfc603cd-423d85cb-2137-4ea2-9b4c-357098826b3f" into x
if x is y then
answer "true"
else
answer "false"
end if
end mouseUp


-Replace "Password" with your desired password.

3. Compile the application into an executable form.

4. Use a decompilation tool (e.g., x64dbg) to view the generated source code.
Note that sensitive strings, including the password set in step 2, are still readable in the generated source code.

Potential Impact:
This bugs could lead to serious security and confidentiality issues with sensitive information in applications developed using LiveCode.

Suggestions:
Stronger code protection or implementation of more secure encryption methods are highly desired for commercial applications developed with LiveCode.


https://quality.livecode.com/show_bug.cgi?id=24518

[keliko]

There are many open-source programming languages where it requires more effort to decompile compared to LiveCode. The option of a script compiler might be considered as a last resort for LiveCode

https://livecode.com/the-script-compiler-project/

[LCMark]

There are many open-source programming languages where it requires more effort to decompile compared to LiveCode

@keliko: Can you give some examples of this, along with the steps you went through to determine that this was harder in those languages?

Looking at your screenshot it looks like you have stepped through the native code in a debugger - this is always going to expose what an app is doing and everything in memory at every point along the way - regardless of what the original programming language was.

It is important to remember that, regardless of programming language, plain text strings *have* to appear in memory at least for a short period of time to actually process them (CPUs don't work on encrypted data, they need the decrypted data).

If these strings are that sensitive they shouldn't be in plain-text in the app at all - for example, they should be encrypted using a password which the user supplies to decrypt on opening the app. If they are for interacting with a server, then they shouldn't be in the client app at all, but instead only stored on the server, and the processes that require them run server-side under request of the client, and never leave the server.

I agree that the script compiler project here will help at least insofar as it will be possible to turn the scripts to bytecode in the standalones, so the original scripts are not present in the standalone executable in any form. However, the *values* themselves will still need to be present and in memory in some form as otherwise how can the CPU process them?

[Tonaras]

@LCMark: How are we supposed to safely and effectively use the following SUPER ESSENTIAL command:

encrypt tText using "rc4-40" with password myPassword()

if the content returned my myPassword() cannot be hidden/obfuscated and remains in RAM until the standalone quits?

I'm begging you for a workable solution to this @LCMark!!


Also, please take notice of Bug 24495 (https://quality.livecode.com/show_bug.cgi?id=24495) which I reported earlier and is highly related to the issue mentioned in this post.

Best regards,
Anton

[FourthWorld]

Anton, please help me understand the scope of risk.

The request is to shorten the length of time in which a decrypted variable remains in memory.

It's understood that the duration cannot be zero, since the unencrypted form must be used during at least one moment.

A potential attacker would need physical access to the system, along with admin privileges sufficient to run low-level debugging tools.

Even when all above conditions required to expose the plain text are met, the provided method of clearing the variable contents sometimes works, with the change that sometimes allows persistence not yet identified.

And even if shortened, the best effort of the LC team cannot completely eliminate all possible risk any more than any other language could, because the duration of the plain text must be non-zero.

Given all these factors, a well-timed dump will always succeed in exposing the decrypted text as would be the case with any language, even if the enhancement request were satisfied.

Is my understanding of the scope of risk correct?


Looking for more complete solutions:

Is the sensitive data being used to access a secure process locally or remotely?

If locally, a complete solution would seem impossible to address within LC alone, as the plain text is used by another process (DB?) LC has no control over.

If remotely, the guidance suggested in Mark's blog post able keeping DB credentials on the server and allowing only user-specific credentials in transit would seem sufficient, isn't it?

What additional details might help me understand the severity as presented?

[stam]

This is an important and recurring topic and clearly a potential risk for newer users.

I know there’s been a blog post on this but what it really needs is an in-depth lesson showing best practices for common scenarios (password hashing, API keys etc).

The lesson needs to be good enough that new users can use safe/safer code for sensitive information… being hacked and blaming a livecode app for this is not to anyone’s benefit and seems a worthwhile investment to me…

[FourthWorld]

I like that suggestion. Elevating this to a Lesson stands a better chance of helping new systems designers adopt industry practices.

[keliko]

@LCMark
As far as I know, the languages that are difficult to decompile are Dart and PureBasic. On YouTube, there are many channels sharing fundamental techniques for reverse engineering, or you can try consulting an expert for this. However, I still like LiveCode because its code can be maintained, and I hope the LiveCode compiler will be released soon.

@Tonaras
The processes you mentioned are typical processes when dumping files or when applications run on a local computer, and even WhatsApp messages can be easily read. In PureBasic, there is a command called `FreeMemory()` and this could be a solution for you if you want to try it. In LiveCode, I haven't found memory management. So, if your application is sensitive, you still need a server-side solution to encrypt using RSA with public and private keys, where only the server can read the message content.

[keliko]

You can perform code obfuscation before creating a standalone application by creating your own commands. Replace functions and commands with meaningless commands and store everything in a local variable, avoiding the use of global variables. Combine functions like encrypt, numToChar, charToNum, codepointToNum, and numToCodepoint,etc. Only LiveCode has the command "go stack url "http://demo.com/random123.livecode"."

Instead of using static commands, always opt for dynamic ones. For instance, rather than using the command "go stack url "http://demo.com/random123.livecode", it's better to have the file random123.livecode changing continuously over time. This approach requires server-side assistance.

You can create your own algorithm, which will add an additional layer of protection to your application.

Even I use Docker and PuTTY to create users in a switching manner and use "go stack url" to obtain passwords, rather than hard-coding them into your application. The PuTTY library enables you to communicate with a server. Using "shell()" and "open process" commands creates an asynchronous function without waiting for completion.

Using HTTP protocol (port 80) can be easily intercepted with tools like Proxyman or Charles. I prefer using port 22 because LiveCode does not have an `ssh()` command, so I use PuTTY.

I've tried this on Windows, and indeed, these steps make it more difficult to reverse engineer your LiveCode application.
The final solution is that you should build a Software as a Service (SaaS) instead of distributing your application to users.

[FourthWorld]

Using HTTP protocol (port 80) can be easily intercepted with tools like Proxyman or Charles. I prefer using port 22 because LiveCode does not have an `ssh()` command, so I use PuTTY.

LiveCode supports HTTPS, the most common solution for secure file retrieval and API calls.

[keliko]

What I mean is, using HTTP/HTTPS protocols makes it easy to debug using tools like Proxyman and Charles Proxy. However, I haven't found a tool that can read data streams when using port 22. Even with Wireshark, analysis is only possible up to the exchange of public and private keys.

[FourthWorld]

What I mean is, using HTTP/HTTPS protocols makes it easy to debug using tools like Proxyman and Charles Proxy. However, I haven't found a tool that can read data streams when using port 22. Even with Wireshark, analysis is only possible up to the exchange of public and private keys.

The encryption used with HTTPS and ssh are similar enough that Wireshark, Little Snitch, etc should exhibit the same observability with both: packets visible but unreadable in transit.

The main difference is in application: they're designed for such different purposes I wouldn't encourage newcomers to consider them interchangeable.

SSH is the go-to for admin access, and HTTPS for client-facing data retrieval and API services.

[keliko]

Have you ever successfully read the contents of messages or files sent via SFTP using any tool?
I have never succeeded in doing so. I would like to learn what method you use.
If you are using Proxyman or Charles, it is very easy to read encrypted message contents.

[FourthWorld]

Sounds like incomplete tool implementation.

I can read everything I type. Physical access= root.

The question is, can the bad guys read it?