Após a discussãoAqui, se você quiser ter uma classe segura para armazenar informações confidenciais (por exemplo, senhas) na memória, é necessário:

memset / limpe a memória antes de liberá-larealocações também devem seguir a mesma regra - em vez de usar realloc, use malloc para criar uma nova região de memória, copie o antigo para o novo e então memset / limpe a memória antiga antes de liberá-la finalmente

Então, isso soa bem, e eu criei uma classe de teste para ver se isso funciona. Então eu fiz um teste simples onde eu continuo adicionando as palavras "LOL" e "WUT", seguidas por um número para essa classe de buffer seguro em torno de mil vezes, destruindo aquele objeto, antes de finalmente fazer algo que causa um dump principal.

Como a classe deve limpar com segurança a memória antes da destruição, não devo encontrar um "LOLWUT" no coredump. No entanto, eu ainda consegui encontrá-los, e me perguntei se a minha implementação é apenas buggy. No entanto, eu tentei a mesma coisa usando o SecByteBlock da biblioteca CryptoPP:

#include <cryptopp/osrng.h>
#include <cryptopp/dh.h>
#include <cryptopp/sha.h>
#include <cryptopp/aes.h>
#include <cryptopp/modes.h>
#include <cryptopp/filters.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
using namespace std;

int main(){
   {
      CryptoPP::SecByteBlock moo;

      int i;
      for(i = 0; i < 234; i++){
         moo += (CryptoPP::SecByteBlock((byte*)"LOL", 3));
         moo += (CryptoPP::SecByteBlock((byte*)"WUT", 3));

         char buffer[33];
         sprintf(buffer, "%d", i);
         string thenumber (buffer);

         moo += (CryptoPP::SecByteBlock((byte*)thenumber.c_str(), thenumber.size()));
      }

      moo.CleanNew(0);

   }

   sleep(1);

   *((int*)NULL) = 1;

   return 0;
}

E então compile usando:

g++ clearer.cpp -lcryptopp -O0

E depois ativar o core dump

ulimit -c 99999999

Mas, então, habilitar o core dump e executá-lo

./a.out ; grep LOLWUT core ; echo hello

dá a seguinte saída

Segmentation fault (core dumped)
Binary file core matches
hello

O quê está causando isto? Toda a região de memória para o aplicativo realocou-se, devido à realocação causada pelo acréscimo do SecByteBlock?

Além disso,Esta é a documentação do SecByteBlock

editar: Depois de verificar o core dump usando vim, eu tenho isso:http://imgur.com/owkaw

edit2: código atualizado para que seja mais facilmente compilável e instruções de compilação

edição final3: Parece que memcpy é o culpado. Veja o Rasmus 'mymemcpy implementação em sua resposta abaixo.