а не кажется Вам, что с такими вопросами вы возьмёте на работу заучку-ботана. который наизусть знает все формулировки, но не сможет решить нестандартной задачи.
не нашёл в ничего такого, что прояснило бы ситуацию. ведь в описании не спроста фигурирует сеть и лог траффика. на мой взгляд, основная задача — маскировка пакетов с данными под системные пакеты.
очевидно то, что уже классификация — троян, это описание принципиального устройства. а вот «передает и принимает какие-либо данные»» -условие задачи. иначе задача ставилась бы «написание трояна, который не использует сеть»
первым условием задачи стоит "«есть трой, он ПЕРЕДАЁТ и ПРИНИМАЕТ какие-либо данные»". второе условие «невозможно было доказать». на основании чего вы сможете доказать, что syn пакет содержит полезные данные. из кода трояны вы ничего получить не сможете. там только стандартные процедуры. просто одним словом — на каком основании?
итак условия:
«есть трой, он передает и принимает какие-либо данные» (т.е. пакеты в сеть он отсылает и в логах будет в любом случае)
далее:
«если трой будет найден и весь трафик идущий по сети сохранен невозможно было доказать что он передавал какие-либо данные»
т.е поля данных в пакетах должны быть максимально прозрачны, а в коде трояна не должно быть даже намёка на работу с ними, так же как и какого-либо шифрования, преобразования и т.п. только стандартные операции.
на сколько я понял известен не алгоритм, а код. цитата: «если трой будет найден и весь трафик идущий по сети сохранен невозможно было доказать что он передавал какие-либо данные». разобрав код вы не найдёте никаких операций с данными, анализируя пакеты не найдёте ни каких аномалий.
прекрасно, пусть оно будет в логах. только как вы отличите его от других таких же пакетов? если троян является, скажем, плагином для файерфокса. в коде вы видите только попытку установить соединение с сервером и ничего более. посылаемые пакеты тоже стандартные.
извиняюсь за своё костноязычие, видимо не правильно объясняю. попробую по-другому. допустим посылаю я серверу syn пакет. в
segment's sequence (32 бита) должно стоять рандомное значение. мой алгоритм псевдо-рандома предполагает получение его из потока аудио устройства. это всё, что будет в коде трояна. ничего необычного. другое дело, что предворительно в аудиопоток будут внесены нужные данные. вот, как то так.
в том то и дело, что алгорим генерации случайного значения не играет роли. грубый пример: я генерирую random читая выход с аудио карты, а нужная информация идёт на её вход.
а как вам такой вариант решения, допустим протокол подразумевает передачу какого-либо случайного значения. случайное значение в свою очередь генирится из данных которые нужно передать, а на принимающем хосте востанавливаются. тут по сути слабый random.
а никак к флешке дополнительно запрос ПИНа не привязать, по аналогии со смарткартой. а то кража флешки злобным сослуживцем даст ему полный доступ к профилю.
опрос — не совсем точное понятие. слейв не спрашивает мастера, он получает от него пакеты. если в определённый момент пакет не пришёл — тогда и нужно спешить на помощь. «определённый момент» настраиваится опцией --deadratio=NUM. Где num по умолчанию равен 3.
Мастер-хост группы регулярно рассылает объявления по сети, с целью оповестить остальные машины группы, что он все еще работоспособен. В случае, если резервной машиной объявление не будет получено в течение заданного интервала, то она перехватывает функции мастер-хоста (та из них, которая имеет меньшие значения UCARP_ADVBASE).
еще есть замечательная утилитка truecrypt, которой можно шифровать целые разделы. огромным приемуществом также является поддержка практически всех платформ. оч. удобно зашифровать раздел на флешке и пользовать его под любой осью.
«есть трой, он передает и принимает какие-либо данные» (т.е. пакеты в сеть он отсылает и в логах будет в любом случае)
далее:
«если трой будет найден и весь трафик идущий по сети сохранен невозможно было доказать что он передавал какие-либо данные»
т.е поля данных в пакетах должны быть максимально прозрачны, а в коде трояна не должно быть даже намёка на работу с ними, так же как и какого-либо шифрования, преобразования и т.п. только стандартные операции.
такая задача, или?
segment's sequence (32 бита) должно стоять рандомное значение. мой алгоритм псевдо-рандома предполагает получение его из потока аудио устройства. это всё, что будет в коде трояна. ничего необычного. другое дело, что предворительно в аудиопоток будут внесены нужные данные. вот, как то так.