Detecting if desktop app's memory is being scanned

At the MBS Munich conference @Christian Schmitz gave an excellent, but terrifying talk about how your running desktop app’s memory and variables can be examined by an externally running app via breakpoints. Unfortunately he gave no tangible solutions, but hinted you could detect if your app was being scanned and thus quit immediately.

How can I detect if my desktop is having its memory scanned?

But this is Windows only, or?

Christian’s demo was on macOS, but I assume there are even more tools for this on Windows. I would need it cross-platform.

I encrypt and obfuscate all my passwords and usernames, but all that is pointless if someone can find out the password from RAM once it was decrypted, just before a connection.

.NET has datatype called SecureString which is for this purpose, as in it cannot be pried easily from memory.

But surely the username and password are sitting in plain text inside the Xojo or MBS database connection class. Or if I need to connect to an SFTP server or AWS server, these will need the decrypted username/password/accesskey/secretkey to connect and so are stored somewhere in RAM, so a SecureString only goes to far.

Idea with SecureString classes is you store them there during the time you need to store it, then you decode just at the point where you need to use it.

The chain of security is better as more links in the chain know how to use the SecureString, like a Connection class would be good candidate to know how to use such.

Same if your storing password to log into some web service then one would store it in SecureString and only decode right at the point you use it and not store the decoded string. (And preferably clean it up after use by writing over the same bytes)

The aim of my thread is to determine IF the RAM or app is being scanned eg just before I decrypt the strings and make a connection. I have the encryption side licked.

So I think it depends on how the classes we are using are designed? So for example, do the database classes internally encrypt the password being stored, or is it just plaintext? Is the password property a regular property or a computed property with some work done in the background to encrypt/decrypt?

I agree. When I run as debug I can see the username and password in all Xojo and MBS database/CURL connections as plain text. I am not sure if it is still in plain text in non-Debug mode.

This is very interesting. I have a client that needs to protect certain information in memory (like from injectors and other process memory reading) and SecureString sounds like the ticket. Is there any kind of video/text on this conference topic?

This interests me as disassembly or scanning memory is probably the most likely way someone would try to mess with my app. I noticed it’s not easy to see much with a resource editor on the EXE file but haven’t tried monitoring the memory in use. Is there as simple as doing a memory dump or is there a suitable windows app for live monitoring this kind of thing?

I was thinking about creating SecureString class, but…since Xojo strings are not mutatable then there is no way to zero their memory in valid way. Which would mean also if a database connection class encrypts their stored password then you still have no way to ensure that the plain text string you passed in dies in proper way and that its memory gets zero’ed.

Hi David,
The example given by Christian showed how to find the encryption key for a database and according to him, one of the possibilities would be to check the execution time to see if the program was stopped.

I did not try this solution, but I would do it by specifying a fake encryption key and check the time taken by the system to determine if there was a break or not. If the time is a few microseconds or milliseconds the program works correctly, but if the time is in seconds, there is definitely a stop. If you detect a stop you can leave the program and other way indicate the right key and continue.

Example:

[code]dim db as new SQLiteDatabase
dim t As Double = Microseconds

db.EncryptionKey = “fake pass…”
if Microseconds-t > 1000000 Then Return //Quit or … if more than 1 sec. to assign pass

db.EncryptionKey = Decode(Your real encoded pass)
If db.Connect Then
…[/code]

Just an idea to try…

On Windows, you can use Task manager to right click on the process and select to write app memory to a file.
Than you see all memory.

Things you can do is:

  1. Watch videos from conference.
  2. Limit the time plain text is stored in memory. e.g. clear the password property after connecting.
  3. Store things encrypted long term.
  4. Measure how quick app runs, e.g. take times in methods to detect if you are debugged and do things differently.

The demo was to read parameter passed to EncryptionKey property setter. But if that is maybe a Hash (SHA256 for example) of a text, they may get the hash, but don’t know the original key entered. Don’t forget the salt.

Just by replacing the value of the string with dummy characters ? [quote=406161:@Christian Schmitz]Don’t forget the salt.[/quote]

[quote=406161:@Christian Schmitz]Don’t forget the salt.[/quote] (??)

You assign the property of Database class.
And after you are connected, you can assign it again with no value.

If you hash something, always use a salt.

[Sorry, maybe not directly related with the subject question] I think this can be a good reading: https://crackstation.net/hashing-security.htm

Look realistically if someone has sufficient privileges to start scanning memory, using debug tools etc, then you can also assume they will have the ability to run a sniffer on the network, fake an SSL connection etc… in other words the game is up!

What you might try is check for installed applications and running processes when you start up and if it looks like it is not your typical business user’s machine just quit.

[quote=406160:@Alain Clausen]Hi David,
The example given by Christian showed how to find the encryption key for a database and according to him, one of the possibilities would be to check the execution time to see if the program was stopped.

I did not try this solution, but I would do it by specifying a fake encryption key and check the time taken by the system to determine if there was a break or not. If the time is a few microseconds or milliseconds the program works correctly, but if the time is in seconds, there is definitely a stop. If you detect a stop you can leave the program and other way indicate the right key and continue.

Example:

[code]dim db as new SQLiteDatabase
dim t As Double = Microseconds

db.EncryptionKey = “fake pass…”
if Microseconds-t > 1000000 Then Return //Quit or … if more than 1 sec. to assign pass

db.EncryptionKey = Decode(Your real encoded pass)
If db.Connect Then
…[/code]
Just an idea to try…[/quote]

I am using this technique for a long time now.
I do not quit the app but do something unexpected so the app will behave odd in places. This is much harder to crack. If you just quit, it can be easily bypassed next time.

[quote=406180:@Christoph De Vocht]I am using this technique for a long time now.
I do not quit the app butcdo something unexpected so the app will behave odd in places. This is much harder to crack. If you quit, it can be easily bypassed next time.[/quote]

so technically the app can send u email saying someone is hacking the app… at whatever time