Передача данных между модулями

[Tema]

Мне необходимо разбить программу на части (н-р по DLL), но надо чтобы при передаче информации из одной DLL в другую ее нельзя было бы перехватить.

[Finch]

Информацию, то можно всегда перехватить, если знаеш что она передается. Просто надо скрывать сам факт передачи. Значит надо использовать нестандартные способы передачи информации. Если происходит передача стандартными методами, тогда шифровать. Но встает вопрос, а для чего это нужно?

[Джон]

Tema, по большому так сделать нельзя (ura nora - nostra ales). Можно усложнить такой перехват. Для конкретных советов не хватает инфы, что за ДЛЛ, какого типа информация  и тп

[Tema]

Например: DLL с функциями шифрования.

Не обязательно использовать DLL, в принципе, задача такова: необходимо чтобы программа состояла из нескольких частей (возможность замены новой версией): шифрование, почтовый клиент, хранение информации...

[Джон]

Не думаю, что тебе удастся полностью скрыть факт передачи данных. По большому счёту тебе нужны алгоритмы шифрования, а уж где они используются - только в EXE или в DLL, сам решай. Сложность этих алгоритмов обычно зависит от ценности информации. Действует золотое правило, если защита инфы стоит дороже, чем сама инфа, то её просто не защищают.

[npak]

А в чём проблема?  DLL находятся в одном процессе или в разных?  Если в одном, то достаточно простого процедурного вызова.  Если DLL находятся в разных процессах, то надо определиться с атакой, от которой будет строиться защита.

Есть как минимум несколько возможных атак:

1.  Обнаружение факта передачи данных
2.  Получение доступа к передаваемым данным
3.  Препятствование передаче

Далее, какими ресурсами располагает противник.  Есть классификация противников на три категории:
1.  Чайник -- не обладает специальными знаниями и инструментами
2.  Умелец-любитель -- есть знания и умения, но нет специальных инструментов или приходится создавать их самостоятельно.
3.  Профессионал на службе у организации -- есть знания и умения, есть спец. инструментарий и поддержка по разработке нового.

Tema, какие атаки ты хочешь отразить, и кто вероятный противник?  Стоит ли объект защиты необходимых усилий?

[Tema]

DLL находится в одном процессе ( LoadLibrary() ), но разве нельзя будет противнику заменить мою DLL на свою с теми же функциями и быть прослойкой между основной программой и моей DLL, перехватывая все вызовы функций и, соответственно, все данные?

Нельзя дать возможность противнику получить незащищенные данные. Противник – профи. Объект стоит значительных усилий, т.к. именно секретность информации лежит в основе моей программы.

Может не пыжиться и включить шифрование данных не в отдельную ДЛЛ, а в ЕХЕ?

[npak]

Если защита делается от профи, то шифрованием не обойдёшся.  Противник может запустить программу в отладчике, дождаться, пока данные будут расшифрованы, и получить их прямым чтением из памяти.  Или прочитать из памяти вызывающего модуля до вызова (исходные данные) или после вызова расшифрованные результаты.

Для защиты от чтения памяти в отладчике есть несколько методов, которые надо применять согласованно. 
В LoadLibrary загружать только по полному пути, без сокращений.  Далее, в код DLL надо встроить проверки контрольной суммы модуля DLL -- прочитать файл, который был загружен, и посчитать для него какую-либо контрольную сумму (наиболее известные -- md5 и sha1).  Эта мера поможет защититься от подмены файла DLL и заставит противника ковыряться с кодом твоей DLL в поисках обхода механизма аутентификации модуля.  Ещё один необходимый шаг -- запутывание кода.  При запутывании поток управления и поток данных разбавляется всяким хламом, который не меняет логику работы программы, но сильно усложняет анализ.  Есть множество запутывателей (obfuscators) разной степени сложности, но надо помнить, что все виды запутывания замедляют работу программы выполнением маскирующих инструкций и увеличивают объём кода.

Шифрование, собственно, становится не нужным, так как аутентификация модуля усложнит использование закладок, а запутывание кода и данных потребует от противника больших усилий по восстановлению секретных данных

[michaelprog]

почитай о том, как умельцы ломали защиту: http://www.bugtraq.ru/library/programming/crksteps.html
очень познавательно

[Tema]

Всем спасибо. Вопрос стал более понятен.

[Finch]

npak Взломать зашиту библиотеки по контрольной сумме очень легко. Достаточно перехватить вызов самой функции. Технику достаточно хорошо описал Рихтер. Но что именно надо перехватывать, я бы не хотел говорить. Другое дело замыливание кода. И передача данных косвенным путем. Чтобы противник ничего незаподозрил, в функциюю можно кидать какие либо данные и шифровать их честным путем. Но при этом это будет сигнал, что посланы данные для обработки косвенным путем. Один из видов, может быть FileMapping. Два модуля должны знать точное название проекции файла. Тогда они смогут работать. Есть одно но, может быть полный скан памяти, на изменения. И определения областей изменения.

[npak]

Finch,

Тогда остаётся совместное использование шифрования, защиты от прогона под отладчиком, запутывание кода.

Правда, мне кажется, что есть достаточно надёжные средства взаимной аутентификации вызывающей стороны и DLL.