Clear created Object memory

Question

i'm using WMI SMBios to get some hardware information

check uSMBios.pas

i don't wanna users see what is the used serial numbers in memory so i'm trying to clear it

when i call

SMBios:=TSMBios.Create;
//my code
SMBios.free;

the SMBios Object still in memory in many locations

i tried this code on Destroy Event

    if Assigned(FRawSMBIOSData.SMBIOSTableData) then
    begin
      ZeroMemory(FRawSMBIOSData.SMBIOSTableData,FRawSMBIOSData.Length);
      FreeMem(FRawSMBIOSData.SMBIOSTableData);
    end;

it working great with GetSystemFirmwareTable API code in SMBios but in WMI it removes some memory but still i can find few blocks

wondering why after calling object.free or freeandnil the used memory not released

any idea how to force the application to free it ?

Answer 1

Memory is released, it is just not wiped. You maybe mistake two concepts: the memory is bound to some owner and cannot be given to another one, and memory is cleansed of all the information.

Look, when you go over fresh snow or over sands, you leave your footsteps behind you. You moved away, so the places you've been through are FREE now for anyone else to occupy. But your footsteps remain there until someone would overwrite them with his own ones.

Now, you may be paranoid and after every step you would turn back, take a brush and remove your fresh footstep. That is possible and might make sense, but it might be painfully slow.

Some objects might deal with sensitive data, like passwords, cipher keys, personal data in mass calculations, etc. For those objects there is the sense to be paranoid and brush out every their trace. So those objects are written in a way to wipe the memory they would no more need immediately after last use. And to do it once again in the destructor.

But when you just closed the form with the message like "file saved successfully" there ain't any secrets worth painting over. And that is the most of the program.

So now please decide if you really have some sensitive data like passwords. If you do - your code should overwrite it with different data before freeing. And you would have to learn how the data is kept for different types in Delphi, so pieces of the data would not be copied in other places of memory during your processing of them. But most probably you don't need the data actually destroyed, you only need to mark "this place is FREE for anyone to put their data over my garbage" and that is what freeing object on Delphi actually does. If that is enough for you just don't you bother to wipe the data (which is substituting random garbage instead of sensitive garbage, but a garbage still).

Now, few words about suggestions of LU RD and whosrdaddy. Yes, Delphi provides you means to hook into the way heap is managed and to explicitly wipe the data with garbage before marking the apartment free. However this is only a partial solution for sensitive data.

• 99,9% of times you would be clearing data that was not worth it. Strings, dynamic arrays, TList and other containers would be slow - and your program too.
• your app consists of procedures, that have local variables. Many of those variables, like Short Strings, fixed size arrays, GUIDs, are allocated on stack rather than in heap. Those suggestions would not clean them, only free.
• your objects typically allocate memory in Delphi heap. But they might also allocate it otherwise. In Windows heap, in some multithreading-aware pool, or whatever. That memory would not be wiped modifying default Delphi heap manager behavior.

Overall it is the same idea. Your procedure or your object knows which data is dangerous and where it is kept - that object or procedure is responsible of cleansing. Global Delphi-scale solutions would be both ineffective and unreliable.