После обсужденияВотЕсли вы хотите иметь безопасный класс для хранения конфиденциальной информации (например, паролей) в памяти, вам необходимо:

memset/clear the memory before freeing it reallocations must also follow the same rule - instead of using realloc, use malloc to create a new memory region, copy the old to the new, and then memset/clear the old memory before freeing it finally

Это звучит хорошо, и я создал тестовый класс, чтобы посмотреть, работает ли он. Поэтому я сделал простой тестовый пример, в котором я продолжаю добавлять слова «LOL». и "WUT", за которым следует тысяча раз, чтобы этот класс защищенного буфера уничтожил этот объект, прежде чем, наконец, сделать что-то, что вызывает дамп ядра.

Поскольку класс должен надежно очистить память перед уничтожением, я не должен быть в состоянии найти «LOLWUT». на coredump. Тем не менее, мне удалось найти их до сих пор, и я удивился, если моя реализация просто глючит. Однако я попытался сделать то же самое, используя библиотеку CryptoPP SecByteBlock:

#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;
}

А затем скомпилировать, используя:

g++ clearer.cpp -lcryptopp -O0

А затем включите дамп ядра

ulimit -c 99999999

Но затем, включив дамп ядра и запустив его

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

дает следующий вывод

Segmentation fault (core dumped)
Binary file core matches
hello

Чем это вызвано? Весь регион памяти для приложения перераспределяется из-за перераспределения, вызванного добавлением SecByteBlock?

Также,Это документация SecByteBlock.

editПосле проверки дампа ядра с помощью vim я получил это: http://imgur.com/owkaw

edit2: обновленный код, чтобы его было легче компилировать, и инструкции по компиляции

final edit3Похоже, что memcpy является виновником. Смотри Rasmus & apos;mymemcpy Реализация на его ответ ниже.