а возможно ли в Unix защититься от дизассемблирования???

Это как, вообще? Ты хочешь дать файл, но сделать невозможным его чтение, по сути.

> внутри программы находится ключевая информация
выносить ее в отдельный файл, далее по вкусу алгоритмов криптования

можно написать свой хитрожопый загрузчик, который расшифровывает реальные данные. можно вспомнить времена DOSа и покопаться на тему "зашита от отладки", что по крайней мере осложняет трассировку кода. правда я уже не помню как :)

ps: вот что точно не стоит делать - это слушать красноглазых фанатиков OS. есть интересная инженерная задача - решаем.

// wbr

Давай поближе к делу и поменьше "не слушай всех, кроме меня: они фонатеги", ладно? :) Можно _затруднить_ дизассемблирование. Можно его _сильно_ затруднить. Но не "защитить бинарник от дизассемблирования", правда же?

>можно написать свой хитрожопый загрузчик, который расшифровывает реальные данные.

И всегда ее (программу) можно убить со сбросом в core dump

> Это как, вообще? Ты хочешь дать файл, но сделать невозможным его чтение, по сути.
нет, раньше , на заре 98 виндофф существовали способы усложнения дизасс-я, как уже упоминалось сеня "защита от отладки", но по сути, мне удалось расскопать инфу только для виндофф, а это не то...
естесно полностью защитить прогу от дизасма не удасться, но хотя бы сильно затруднить этот процесс.
проблема состоит в том что прога поставляется на интерактивном загрузочном диске(аля Live CD), если выносить ключевую инфу в файл, то полюбому его надо шифровать, дабы избежать угрозы несанкц-го чтения, если шифровать, то нужен опять таки ключ, а поскольку система LiveCD, то ключ должен быть где-то зашит, и получается мы вернулись к исходной проблеме :%)

> И всегда ее (программу) можно убить со сбросом в core dump

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

> Можно _затруднить_ дизассемблирование. Можно его _сильно_ затруднить. Но не "защитить бинарник от дизассемблирования", правда же?

абсолютной гарантии вам не даст даже сбербанк и весь вопрос как обычно в цене. но затруднить реверсинг несомненно можно.

// wbr

> И всегда ее (программу) можно убить со сбросом в core dump

..с которым работать потом заметно муторнее, нежели с красивым выводом objdump, ведь так?

// wbr

>можно написать свой хитрожопый загрузчик, который расшифровывает
>реальные данные. можно вспомнить времена DOSа и покопаться на тему
>"зашита от отладки", что по крайней мере осложняет трассировку кода.
>правда я уже не помню как :)

>ps: вот что точно не стоит делать - это слушать красноглазых
>фанатиков OS. есть интересная инженерная задача - решаем.

"Давайте жить дружно ;)", а задача дцмаю действительно интересная, так что "Го-Го-Го" - решаем :)
на тему "защита от отладки" рыл, ток для стареньких виндоф :)

> И всегда ее (программу) можно убить со сбросом в core dump

да, и есть это Live CD aka закрытая система, то процесс получения корки может быть сильно затруднен.

// wbr

>да, и есть это Live CD aka закрытая система, то процесс получения корки может быть сильно затруднен.

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

Прежде чем что=либо делать, ответьте себе на несколько вопросов: 1) для кого предназначена программа (то есть кто её будет использовать)? 2) от кото необходимо защитить программу? 3) сколько стоит информация, которую необходимо защитить? 4) как быстро эта информация устаревает?

Вообще говорить о защите непонятно какой информации непонятно от кого не имеет смысла.

>Прежде чем что=либо делать, ответьте себе на несколько вопросов:
> 1)для кого предназначена программа (то есть кто её будет использовать)?
>2) от кото необходимо защитить программу?
>3) сколько стоит информация, которую необходимо защитить?>
4) как быстро эта информация устаревает?

>Вообще говорить о защите непонятно какой информации непонятно от кого не имеет смысла.
я прекрасно понимаю что в основе любой защиты информации лежит в первую очередь определние ценности этой информации и определение ущерба, который может быть нанесен при нарушении безопасности этой информации :)
я разрабатываю защищенный АЛП(автоматизированный лабораторный практикум) по изучению сетевых удаленных атак на протоколы стека TCP/IP, для студентов факультета Б МИФИ и специалистов по спец-и ИБ, проходящих курсы повышения квалификации.
через 6 дней нужно сдать проект и готовый отчет по нему(ТЗ, ПЗ, описание архитектуры и тд и тп), проект в принципе готов, если не брать в рассчет возможность дизассемблирования подсистем АЛП, с целью получения ключевой информации.
если говорить о возможностях злоумыленника, получившего ключевую информацию, то они крайне широки, начиная от подделки результатов тестирования знаний, до нарушения нормального функционирования системы. если конечно же не учитывать организационные меры безопасности, а их учитывать я не могу, т к было требование обойтись по возможности без них :%)

Надо просто сделать защиту таким образом, чтобы её взлом свидетельствовал о том, что обучающийся обладает необходимой квалификацией :)

+ постараться хорошо защитить серверную часть.

Если там студенты дают ответы на какие-то вопросы, то можно ответы посылать на сервер, а уже на сервере проверять правильные ли они и начислять балы.

>Если там студенты дают ответы на какие-то вопросы, то можно ответы посылать на сервер, а уже на сервере проверять правильные ли они и начислять балы.

да все правильно, именно так и сделано, НО сейчас речь идет о защите серверной части(при условии ее хищения, ибо она тоже на LIVE CD), ну и клиентской(для того чтобы пользователь-студент не смог нарушить функционирование системы)
по поводу серверной части: ключ между сервером и клиентом вырабатывается на основе алгоритма Диффи-Хеллмана, что впринципе гласит о том, что чтобы вздамать ключ необходимо решить проблему Дискретного Логарифмирования, все сообщения подписываются с помощью hmac(SHA1), т е с помощью ононаправленнйо хэш-функции с секретом...
за Диффи я не боюсь, а вот за Hmac боюсь, ибо для него ключ зашит в прогу, если злоумышленник получит доступ к клюу hmac, он может осуществить атаку типа DOS на систему, а если нет то не сможет, т к предусмотрена защита от DOS на нескольких разных уровнях


по поводу клиентской части: клиентские части обмениваются между собой системной информацией, которая шифруется с помощью ключа вшитого в клиентскую прогу, и так же подписывается Hmac, если пользователь получит доступ к ключевой информации клиентской части, то он может фальсифицировать пакеты содержащие системную информацию, что может повлечь за собой нарушение протокола выполнения лабораторной работы

>Надо просто сделать защиту таким образом, чтобы её взлом свидетельствовал о том, что обучающийся обладает необходимой квалификацией :)

гы... увы о такой ситуации в ТЗ речь не идет :))))

> да, и есть это Live CD aka закрытая система, то процесс получения корки может быть сильно затруднен.

Этот LiveCD можно из-под qemu запустить, к которому по слухам gdb умеет цепляться. А почитав скрипты и применив ум и сообразительность, возможно и вообще в chroot'е взлетит.

> Этот LiveCD можно из-под qemu запустить, к которому по слухам gdb умеет цепляться. А почитав скрипты и применив ум и сообразительность, возможно и вообще в chroot'е взлетит.

...если они там вообще есть, эти скрипты. можно ведь и полностью переделать всю инициализацию под себя если очень приспичит... ;)

// wbr

> сейчас речь идет о защите серверной части(при условии ее хищения

Вот это самое простое. Шифруешь ответы хоть тем же GPG и пароль НЕ СОХРАНЯЕШЬ на LiveCD, а вводишь его с клавиатуры при запуске.

>Этот LiveCD можно из-под qemu запустить, к которому по слухам gdb умеет цепляться. А почитав скрипты и применив ум и сообразительность, возможно и вообще в chroot'е взлетит.

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

> Вот это самое простое. Шифруешь ответы хоть тем же GPG и пароль НЕ СОХРАНЯЕШЬ на LiveCD, а вводишь его с клавиатуры при запуске.

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

>Этот LiveCD можно из-под qemu запустить, к которому по слухам gdb умеет цепляться. А почитав скрипты и применив ум и сообразительность, возможно и вообще в chroot'е взлетит.

недавно читал статью, в которой рассказывается как можно запустить и проверить на работоспособность второе ядро в Linux;) можно многое :)

Блин я ленивый до самого ужаса... так не хочется переписывать проект под выработку ВСЕХ ключей на основе алгоритма Диффи-хеллмана...
думал что можно что-то попроще придуматть, типа защиты от отладчика... видимо всеж придется все пререписать к чертовой бабушке... :(

НО тем не менее СПАСИБО всем за УЧАСТИЕ и за попытку помочь решить проблему :)

> клиентские части обмениваются между собой системной информацией, которая шифруется с помощью ключа вшитого в клиентскую прогу

Назови мне имя твоего преподавателя, я передам ему твои слова - и наконец-то тебя отчислят. Кодеров, вшивающих данные в код, надо вешать на телеграфых столбах.

> если пользователь получит доступ к ключевой информации клиентской части, то он может фальсифицировать пакеты содержащие системную информацию

Клиника блин.

Есть термин "сеансовый ключ", есть схемы согласования сеансовых ключей, есть схемы аутентификации без передачи пароля - нет ж блин, всегда найдется му^Wстудент, который будет использовать один ключ на все и на всех, и вместо нормального криптографического протокола искать "средства защиты от дизассемблирования".

В идеале схема должна была быть такой: аутентификация клиента на сервере -> Выработка сеансового ключа -> Работа с использованием сеансового ключа -> Завершение сеанса. А базу на сервере просто шифровать с использованием ключа на удаляемом носителе. И все.

по порядку... во-первых скажи с какого перепоя ты решил, что я студент? и что меня могут отчислить?
свои понятия о кодерах, можешь засунуть кда подальше, либо излагать их более мягким стилем, это во-вторых
мне прекранос известны разные схемы согласования общего секретного сеансового ключа, в системе, если ты внимательно читал, как раз такая схема используется, для выработки ключа между клиентом и сервером, т к информация которой они обмениваются наиболее ценна.
вводить такое в клиентские подсистемы просто нет времени, физически его нет, т к нужно писать отчет и доку, и ценность информации которой обмениваются клиентские части между собой не настолько актуальна!
раньше времени тоже не было, так что на это можешь не напират ;)

раскрытие ключей для hmac, может привестис(самое серьезное), только к реализации DOS атаки на серверную или клиентскую часть!
тем более что ключ для hmac задается следующим образом, есть множество для перемешивания, админ задает ключ из 10 символов, эти символы перемешиваются по определенному алгоритму с теми что зашиты в проге и получается ключ 160бит, клиенты тоже вводят ключ для hmac вручную!

no-dashi для тебя вывод только один: научись читать, рпежде чем наезжать на человека растопырив пальцы веером!

Может кому нить когда нить пригодится!
немного инфы по простенькой защите от отладчиков в Linux:
http://www.xakep.ru/magazine/xs/051/100/1.asp
http://www.softportal.com/hotarticles/87
так же нашел в инете вирус линуховый, который использует ptrace как защиту от отладчика, называется он Virus.Linux.Balrog.a («Лаборатория Касперского») также известен как: Linux/Ovets (McAfee), Linux.Ovets (Symantec).
http://www.securitylab.ru/virus/212391.php
Удачи всем :)

http://www.xakep.ru/magazine/xa/092/102/1.asp

Мда... печальная картина с запаковщиками... ну чтож, бум ваять свой клон UPX
СПАСИБО :)

> если конечно же не учитывать организационные меры безопасности, а их учитывать я не могу, т к было требование обойтись по возможности без них :%)

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

Что мешает, например, каждый Live CD сделать уникальным, то есть на каждый Live CD сгенерировать свою пару ключей DSA, а затем выдавать Live CD под роспись в запечатанном пакете.

Можно вопрос? Какого хрена вы вообще самотоятельно реализуете криптографию в production-системе? OpenSSL решил бы все ваши проблемы буквально влет. Насколько я понял из твоих путанных объяснений...

> во-первых скажи с какого перепоя ты решил, что я студент?

Значит, школьник. Только школьник, студент или профессионально непригодный кодер может создать решение, когда доступ к бинарникам сервера способен на значимую величину скомпрометировать данные, хранимые и обрабатываемые на сервере.

Да, в очередной раз убеждаюсь в полной некомпетентности не только большинства студентов, но и сотрудников факультета Б.

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

Вот когда вы сможете отдать исходники сервера и клиента любому студенту, не поставив при этом под угрозу безопасность, это будет защита. Закрытость вас не спасёт, RC4 именно так и взломали.

Кстати, есть подозрение, что вы не с нуля писали код вашего ПО (раз сроки короткие, а работы много). Наверняка, нарушена минимум GPL, так что вас можно просто посадить, если вы не предоставите исходник. Сейчас как раз модно стало судить и сажать за нарушение лицензий на ПО.

>Кстати, есть подозрение, что вы не с нуля писали код вашего ПО (раз сроки короткие, а работы много). Наверняка, нарушена минимум GPL, так что вас можно просто посадить, если вы не предоставите исходник. Сейчас как раз модно стало судить и сажать за нарушение лицензий на ПО.

кстати судят только если продаешь так что идите в лес никто не отменял внутреннего использования всех gpl без открытия своих сорцов

> кстати судят только если продаешь так что идите в лес никто не отменял внутреннего > использования всех gpl без открытия своих сорцов

Поправочка: не "продаёшь", а "распостраняешь", учи английский и читай GPL, если ты кому-либо даёшь свои бинарники (даже в пакетике под роспись) -- это уже распостранение => при грамотном подходе хороший суд.

[code] 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. [/code]

[code] 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. [/code]

Подсказка: (redistribute != sell), запечатанный диск под роспись под понятие "redistribute" попадает.

>Значит, школьник. Только школьник, студент или профессионально
>непригодный кодер может создать решение, когда доступ к бинарникам
>сервера способен на значимую величину скомпрометировать данные,
>хранимые и обрабатываемые на сервере.

Видимо природная лень тебе мешает прочитать что здесь написано ранее!
если ты еще не понял, то используется протокол Диффи-Хеллмана, для выработки одноразового сеансового сектретного ключа! при общении клинтов с сервером!
и в данном случае реализация такова что доступ к бинарникам сервера НЕ ПОЗВОЛЯЕТ СКОМПРОМЕТИРОВАТЬ ДАННЫЕ, хранимые и обрабатываемые на сервере!!!!

>Можно вопрос? Какого хрена вы вообще самотоятельно реализуете
>криптографию в production-системе? OpenSSL решил бы все ваши проблемы
>буквально влет. Насколько я понял из твоих путанных объяснений...

я и использую библиотеку OpenSSL для реализации крипографии ;)
только сетевое взаимодействие пишу сам :)

>Вы не знаете даже основ криптографии, раз строите такую систему. Один из основных постулатов: система не может быть криптостойкой, если её надёжность основывается на закрытости кода (и тем более, на вшивке данных).

фуф... видимо я плохо объясняю... :( надежность не основывается на закрытости кода, надежность основывается на AES и DH(Диффи-хеллман) + Hmac...

>Кстати, есть подозрение, что вы не с нуля писали код вашего ПО (раз сроки короткие, а работы много). Наверняка, нарушена минимум GPL, так что вас можно просто посадить, если вы не предоставите исходник. Сейчас как раз модно стало судить и сажать за нарушение лицензий на ПО.

Пишу с нуля, но использую переработанные утилиты, распространяемые по лицензии GPL(netstat, iptables, tcpdump, bash и тд и тп...), поэтому если я буду распротранять данный продукт за деньги, то меня можно будет засудить... НО распространять я буду по лицензии GPL! а то что мне дадут "премию", или как там это можно назвать... в общем вознагрождение за проделанную работу, никого не ипет, ибо я его не продаю ;)

про некомпетентность некоторых сотрудников фак Б я с вами полностью согласен, но есть и достойные люди... да и вообще все всегда зависит от конкретного человека!

>если я буду распротранять данный продукт за деньги, то меня можно будет засудить...

Нельзя. Можно засудить, за распространение без предоставления исходного кода. А продавать GPL _можно_.

>Нельзя. Можно засудить, за распространение без предоставления исходного кода. А продавать GPL _можно_

фуф... отлично, в любом случае нужно перечитать GPL, я ее уже плохо помню, спасибо :)

> я и использую библиотеку OpenSSL для реализации крипографии ;) только сетевое взаимодействие пишу сам :)

Тогда откуда в клиенте "ключевая информация, которая может привести к нарушению конфиденциальности"? Там нужно ровно одно - _публичный_ ключ сервера. Могу повторить по буквам - П У Б Л И Ч Н Ы Й ;)

Клиентские ключи/пароли должны распространяться отдельно от кода.

> и в данном случае реализация такова что доступ к бинарникам сервера НЕ ПОЗВОЛЯЕТ СКОМПРОМЕТИРОВАТЬ ДАННЫЕ

Ты бы сам себя послушал, а? Цититрую тебя же: "речь идет о защите серверной части(при условии ее хищения, ибо она тоже на LIVE CD), ну и клиентской(для того чтобы пользователь-студент не смог нарушить функционирование системы)".

Так вот в нормальной ситуации наличие отладчика у того, кто получил доступ к серверной части и не имеет ключа на базу, хранимую на сервере, никакого влияния на защищеность информации не оказывает. И защита от отладки НЕ НУЖНА. Как, кстати, и на клиентской части.

>Ты бы сам себя послушал, а? Цититрую тебя же: "речь идет о защите серверной части(при условии ее хищения, ибо она тоже на LIVE CD), ну и клиентской(для того чтобы пользователь-студент не смог нарушить функционирование системы)".


>Так вот в нормальной ситуации наличие отладчика у того, кто получил доступ к серверной части и не имеет ключа на базу, хранимую на сервере, никакого влияния на защищеность информации не оказывает. И защита от отладки НЕ НУЖНА. Как, кстати, и на клиентской части.


единственное для чего нужна защита от отладки, так то для того чтобы злоумышленник не смог реализовать атаку типа DOS на систему, тк на серверной части при получении пакета из сети, прежде чем информация из этого пакета будет отбработана происходят след проверки:

1)port knocking на уровне МЭ(только от определенных IP), если этот этап пробивается, то
2)проверка размера поля данных пакета(обрабатываются только пакеты с определенной длиной поля данных, типа 37 байт...)
3)проверка кода сообщения (R-регистрация, G - генерация ключа...)
4)аутентификация пользователя и проверка целостнисти пакета(проверка HMAC(SHA1), с ключем выработанным по определенному алгоритму на осонове информации зашитой в прогу и пароля задаваемого админом)
5)расшифрование блока данных
6)обработка информации(запроса)

если злоумышленник узнал:
-доверенные IP-адреса,
-последов-ть портов на которые надо постучать,
-узнал что принимаются только пакеты допустим с полем данных = 37 байтам,
-узнал, путем социальной инженерии, пароль выдаваемый админом,
-узнал алгоритм выработки ключа HMAC(SHA1)
то он может посылать пакеты которые не будут расшифрованы, но которые будут проверяться на HMAC... при реализации ДОС атаки, злоумышленник может значительно загрузить сервак, т е ДОС на сервер станет возможным, тк на проверку HMAC требуются системные ресурсы :)

ЗЫ: намного приятней общаться, когда на тебя не наезжают ;)

>то он может посылать пакеты которые не будут расшифрованы, но которые будут проверяться на HMAC...

На сколько я понял админ раздает пароли уникальные для каждого пользователя,

Тогда может:

В конце каждого сеанса зашифровано передаем случайное число, уникальное для данного пользователя. При начале следующего сеанса связи он обязан открыто его передать в не зашифрованном виде.

При авторизации пользователя ищем это число в базе. Если такого нет, бьем тревогу. Если есть производим расшифровку. Если расшифровка не удалась заносим юзера в черный список и обязуем его получить новый пароль у админа.

>В конце каждого сеанса зашифровано передаем случайное число, уникальное для данного пользователя. При начале следующего сеанса связи он обязан открыто его передать в не зашифрованном виде.

>При авторизации пользователя ищем это число в базе. Если такого нет, бьем тревогу. Если есть производим расшифровку. Если расшифровка не удалась заносим юзера в черный список и обязуем его получить новый пароль у админа.

Очннь логичное и трезвое решение, спасибо, я до такого не додумался :) попробую реализовать :)

>В конце каждого сеанса зашифровано передаем случайное число, уникальное для данного пользователя. При начале следующего сеанса связи он обязан открыто его передать в не зашифрованном виде.

>При авторизации пользователя ищем это число в базе. Если такого нет, бьем тревогу. Если есть производим расшифровку. Если расшифровка не удалась заносим юзера в черный список и обязуем его получить новый пароль у админа.

хотя злоумышленник может посредством IP Spoofing постоянно блокировать легальных пользователей, но думаю что-нить придумаю