Security Issue Related to Decompilation in LiveCode
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Security Issue Related to Decompilation in LiveCode
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
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
Re: Security Issue Related to Decompilation in LiveCode
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/
https://livecode.com/the-script-compiler-project/
Re: Security Issue Related to Decompilation in 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?
Re: Security Issue Related to Decompilation in LiveCode
@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
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
-
- VIP Livecode Opensource Backer
- Posts: 9867
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Security Issue Related to Decompilation in LiveCode
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?
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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Security Issue Related to Decompilation in LiveCode
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…
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…
-
- VIP Livecode Opensource Backer
- Posts: 9867
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Security Issue Related to Decompilation in LiveCode
I like that suggestion. Elevating this to a Lesson stands a better chance of helping new systems designers adopt industry practices.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Security Issue Related to Decompilation in LiveCode
@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.
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.
Re: Security Issue Related to Decompilation in LiveCode
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 9867
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Security Issue Related to Decompilation in LiveCode
LiveCode supports HTTPS, the most common solution for secure file retrieval and API calls.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Security Issue Related to Decompilation in LiveCode
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.
-
- VIP Livecode Opensource Backer
- Posts: 9867
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Security Issue Related to Decompilation in LiveCode
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.keliko wrote: ↑Mon Apr 22, 2024 12:32 amWhat 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 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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Security Issue Related to Decompilation in LiveCode
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 9867
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Security Issue Related to Decompilation in LiveCode
Sounds like incomplete tool implementation.
I can read everything I type. Physical access= root.
The question is, can the bad guys read it?
I can read everything I type. Physical access= root.
The question is, can the bad guys read it?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn