Я пишу приложение, которое шифрует свои данные. Затем он может отображать его в незашифрованном виде с помощью пользовательского интерфейса приложения после ввода пароля пользователем. Моя цель — минимизировать доступ к незашифрованным данным в оперативной памяти. Для этого я хочу предотвратить как можно более быструю запись на диск.
Я знаю, что могу настроить рабочий набор моего процесса (вызывая SetProcessWorkingSetSize API), а затем заблокировать эти чувствительные страницы в оперативной памяти (вызывая VirtualLock.) Теоретически, это должно минимизировать шансы его записи на диск.
У меня вопрос, могу ли я сделать то же самое с памятью, которая используется общими элементами управления в моем диалоговом окне, а именно: Редактировать поля, поля со списком, и, самое главное RichEdit контроль?
PS. Я предполагаю, что все они используют данные из куча для моего процесса. Правильный?
РЕДАКТИРОВАТЬ: Видя все комментарии ниже, мне нужно уточнить. Говоря «запереть», я не имею в виду «запереть его замком и ключом, чтобы никто не мог его увидеть». Я имел в виду, заблокировать это как с VirtualLock
API.
Ты можешь использовать EM_SETHANDLE
установить дескриптор для начального выделения элемента управления редактирования, а затем ответить на EN_ERRSPACE
когда (если) ему не хватает места и нужно больше.
Оттуда, вы также можете использовать VirtualLock
на этом блоке памяти, чтобы сохранить его в оперативной памяти как можно больше. Если вы собираетесь делать это много, вы, вероятно, захотите рассмотреть суперклассирование элементов управления, чтобы избежать дублирования кода повсюду.
Что бы там ни было, я не верю, что есть эквивалент для элементов управления расширенным текстом.
На самом деле есть собственный API-интерфейс Windows, который помогает минимизировать уязвимость таких важных элементов, как пароли.
Увидеть CryptProtectMemory в качестве отправной точки.