Secure Erase A String In Memory

[Adrian Verkuil]

Hi Guys,

Say I have a string private in memory and I do
private = private + more_private

Now I wan't to make sure that I overwrite every instance with crap.

My thoughts:

1. Do it in ASM get adress and erase private and more_private
2. Do the same with a pointer

But the real quest is what happens when i do private = private +
Do I have 2 strings or what?

[Mike Doty]

'Would this be a valid test program of what you are trying to do?
If so, not sure about any temp strings. If that is a problem use ASCIIZ.

FUNCTION PBMAIN () AS LONG
  a$ = "A"
  b$ = "B"
  a$ = a$+ b$
  LSET a$ = ""
  LSET b$ = ""
END FUNCTION

[Donald Darden]

The life span of released memory is hard to measure, as memory management is striving to recover memory for other needs. In any case, the contents are lost when the PC is shut down, or the application releases memory back to the system, or you deliberately overwrite it, or the application itself terminates.

But let's say you still want to know how to do it. That is simple enough. You are probably thinking of the content of strings, as numeric data is less obvious as to what its value signifies. So here is a simple overwrite of a string:

FOR a = 1 to LEN(aa$)
    MID$(aa$,1)=CHR$(RND(0,255))
NEXT

You can also use POKE and STRPTR as another approach.

The problem is, that if you suspect that some sort of worm or whatever is crawling around your memory and fetching your "private" data, then what makes you think that it hasn't already found your private data before you overwrite it? And where is this "private" data before and after it is in the computer memory? If in your head, then just the act of typing it in might mean exposure to a keystroke logger, and if on a hard drive, it is far more persistent there and subject to being found than while it is in memory.

In other words, having your "private" data in your PC's memory is probably safer than some of the other places where you might have it.

[Mike Doty]

Totally agree.
Note: using chr$(0) to blank memory doesn't work assigning to variable
'it only blanks to length of previous value marked by ascii 0 in string.
LSET aa$ = STRING$(LargeValue,1 or higher) does work.

There is an accidental problem in that loop
MID$(aa$,1)=CHR$(RND(0,255)) should be MID$(aa,a) = CHR(RND(0,255))

Note: Using LEN may not work because the length of the last string
placed into a ASCIIZ string may be shorter than the length allowed and
a longer string may have been in there before so the tail of it will display.

I'd bet he wants to leave as little left in memory to read by others when the program ends.

This is sort of interesting showing assigning values does not always update all the assigned area in memory.

FUNCTION PBMAIN AS LONG
  LOCAL a AS ASCIIZ * 10
  LOCAL value AS LONG
  LOCAL x AS LONG
  LOCAL address AS DWORD
 
  a = STRING$(9,99)
  address = VARPTR(a)
  a = "12345"
 
  ? "BEFORE"
  FOR x = 0 TO 9
    value = PEEK(address + x)
    ? value;
  NEXT
  ?
  a = ""                'does not work, only fills to first ascii 0 found
  LSET a = ""           'does not work, only fills to first ascii 0 found
  a = CHR$(0,200)       'does not work, only fills to first ascii 0 found
  'a = STRING$(9999,1)  'works, unremark to see results
 
  ? "AFTER"
  FOR x = 0 TO 9
    value = PEEK(address+x)
    ? value;
  NEXT
  WAITKEY$
END FUNCTION

[Adrian Verkuil]

Mike and Don,

Now I think about this maybe a better solution would be this,
Reserve a block of mem say 4096 bytes as ASCIIZ and make sure all string proccesing takes places in that block.
That leaves the problem that you have to make special routines to handle the block, I think that for example : block$ = mid$(block$,10,5) will create a tmp string outside the block.

I think I go for this leave all strings before alone,
Create asciiz block, do a final encode off that block with ASM
so at least I will be sure then that no tmp or other data leaks outside the block. Use the pw string from the block erase block.

[Michael Mattias]

Assignment to a dynamic string does not necessarily change the string data in the far heap; however, that data are inaccessible to the process once that happens.

The only way to blank out the memory is to explicitly overwrite it.

e.g as shown above ...

  POKE$  STRPTR(stringvar$), SPACE$(LEN(stringvar$))

OR

  TYPE SET asciizVar = SPACE$(SIZEOF(asciizvar)-1) ' -1 optional

MCM

[Michael Mattias]

But the real quest is what happens when i do private = private +
Do I have 2 strings or what

You have one string accessible to your program. The data (the new string) are in contiguous memory in the far heap. The original string may or may not be lying around somewhere in the far heap, at least for a little while, until your process needs more memory for something, but it won't be accessible to your program.

[Mike Doty]

Sounds good.
Poking/peeking encoded/decoded values into blocks should do the trick.
I've never poked a location and refreshed with DDT, interesting.
Sounds like a great password input method. I'd also avoid static or global
so the memory location changes.

On second thought, maybe a global would make life easier if the block was encrypted.

[Adrian Verkuil]

So resume,


1. Use ASCIIZ because memloc is fixed as an offset to the stack.
2. Make sure to destroy contents before the sub or function ends,
next time you use the func or sub the old mem is released and a new one assigned! if I read the manual correct

[Mike Doty]

Another concern might be passed values.

[Adrian Verkuil]

Mike,

For example:

User type in his pw as he knows it.

Say 12345 in asciiz string 01

your algo makes that

[email protected]#$ in asciiz string 02

Now do this Encode 01 with 2 use output as PW destroy both strings.

That will do the trick

[Michael Mattias]

What's with all the 'encoding' or 'random characters?'

Overwriting with SPACE or NUL or "X" is just as much, to use your own word, "crap" as would be some kind of encoding.

That which can be encoded can be decoded.

Unsolicited and close-to-gratuitous comment: You are either worried about nothing or doing something the hard way.

[John Harvill]

You can secure the contents of your string variables with fixed-length global strings, which don't get copied from location to location in memory. For example,

 
#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"
GLOBAL s1 AS STRING*50
FUNCTION PBMAIN () AS LONG
   OPEN "output.txt" FOR OUTPUT AS #12
 
   s1 = "This is data in my secure string"
   PRINT #12, "s1 = "; s1
   PRINT #12, "Size of s1 = "; SIZEOF( s1 )
   PRINT #12, "Location of s1 = "; VARPTR( s1 )
   PRINT #12, "-------------------"
 
'  Overwrite the contents of s1 in memory
   s1 = REPEAT$( SIZEOF( s1 ), "x" )
   PRINT #12, "s1 = "; s1
   PRINT #12, "Size of s1 = "; SIZEOF( s1 )
   PRINT #12, "Location of s1 = "; VARPTR( s1 )
 
   CLOSE #12
END FUNCTION

However, I don't know whether the compiler is leaving temporary copies of the string in temporary variables.

John Harvill

[Mike Doty]

That could leave memory in cache and possibly the page file.

[Donald Darden]

Let me repeat again, that this is really a non issue, and anybody that thinks that they have to do things this way has no idea of what they are talking about.

However, the discussion has some merit as it helps people understand how data is handled internally.

First of all, the data is inaccessible outside of your program. Programs are kept apart from each other, as is the data that they work with. If someone can defeat the checks that the operating system has on your virtual space, than they can do anything they want, including causing your program to stop where they want, or step though its execution and see what it actually does. Your clever little tricks are meaningless in that case.

Encrypted data is only safe until it is unencrypted. If your program is using the data, then at some point it is exposed internally. It would take an exceptionally skilled programmer to get to it, and even then he would have to know what he is looking for.

Programs are not smart enough to "recognize" information on their own. You can recognize an email address by an included @ with non-space characters before and after it. You can recognize a phone number by its pattern: (###) ###-####, or ###-###-####, or any of a number of common forms. You can recognize a social security number by its form: ###-##-####. A program can be made to recognize what we know to look for. But you get much beyond special cases and into general syntax, and all the program can do is recognize probable text and look up what appears to be words.

If programs returned everything that they find, we would be swamped in cryptic symbols and bits and pieces of what might be words. Look at a .DOC file with a plain text editor, and realize that most of what you can't understand is formatting instructions for Word to know how to display the contained information. We don't even have viewable symbols for a lot of the codes, so you may see squares or something else substituted.

Yours is not the only program running. Use the Task Manager and count the number of processes all running at once. Memory is constantly being allocated and recovered, and a program does not get the same block of memory every time. When the program ends, that block of memory is put to other use.

So be clever if you want, but there's not much point to it. It's like trying to walk backwards and use a broom to cover your tracks, when the rain is already washing them away.

I see the error in my code, but it was late, and I did know better. If you retain a variable long enough to write directly into its stored contents, it does not matter what you put there, you will change the original contents. But computer memory does not have the presistency of a hard drive, so the secure erase process recommended for hard drives really does not pertain to RAM.

However, strickly for the merit of further discussion, I will add that using a LOCAL variable in s SUB or FUNCTION places it on the stack, and while the contents of the stack do remain after a sub or function is exited, all information below the stack pointer is considered trashed. And the next call to any sub or function will overwrite the previous, to a greater or lesser degree, and your program is not the only one relying on the stack, so even if you don't make other calls, other processes and programs will.

To put it another way, look at the wake that a boat makes as it moves through the water. It doesn't take long before the wake is gone, and though the water may still show expanding ripples, nobody can tell what passed that way in the aftermath.

[Michael Mattias]

......look at the wake that a boat makes as it moves through the water...... expanding ripples....in the aftermath...

Wow.

That's Really REALLY profound, Donald. Are you sharing whatever you were smoking when you wrote that?

On the more substantive matter, the rest of your post is right on!

MCM

[Cliff Nichols]

Donald had the point right on....
Although methinks not a smokin something but more experience with ripples and waves

Sometimes something as simple as a comment is all it takes for a lightbulb to go from dim, to brilliant (even if its a short example)

One thing I like about Donald, is Life experience (take it if you like it, spurn it if you hate it....but all in all you MUST learn from it)