Siguiendo la discusiónaquíSi desea tener una clase segura para almacenar información confidencial (por ejemplo, contraseñas) en la memoria, debe:

memset / borrar la memoria antes de liberarlolas reasignaciones también deben seguir la misma regla: en lugar de usar realloc, use malloc para crear una nueva región de memoria, copie la antigua a la nueva y luego memset / clear la memoria antigua antes de liberarla finalmente

Así que esto suena bien, y creé una clase de prueba para ver si esto funciona. Así que hice un caso de prueba simple en el que seguí agregando las palabras "LOL" y "WUT", seguidas de un número a esta clase de búfer seguro unas mil veces, destruyendo ese objeto, antes de finalmente hacer algo que cause un volcado de memoria.

Dado que se supone que la clase debe borrar de forma segura la memoria antes de la destrucción, no se supone que yo pueda encontrar un "LOLWUT" en el coredump. Sin embargo, logré encontrarlos todavía, y me pregunté si mi implementación está llena de errores. Sin embargo, intenté lo mismo usando SecByteBlock de la 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;
}

Y luego compilar usando:

g++ clearer.cpp -lcryptopp -O0

Y luego habilitar volcado de núcleo

ulimit -c 99999999

Pero entonces, habilitar el volcado de núcleo y ejecutarlo

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

da la siguiente salida

Segmentation fault (core dumped)
Binary file core matches
hello

¿Qué está causando esto? ¿Se reasignó toda la región de memoria para la aplicación, debido a la reasignación causada por el apéndice de SecByteBlock?

También,Esta es la documentación de SecByteBlock

editar: Después de verificar el volcado de núcleo usando vim, obtuve esto:http://imgur.com/owkaw

edit2: código actualizado para que sea más fácil de compilar e instrucciones de compilación

edit3 final: Parece que memcpy es el culpable. Ver rasmus 'mymemcpy Implementación en su respuesta a continuación.