Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Криптостойкость 0% у любой программы

Автор: delover
Дата сообщения: 13.03.2012 18:30
В этом топике я хочу поделиться своим опытом и ввести новые понятия кардинально отсутствующие в теории которую вы как программисты знаете, а как люди получившие с этого прибыль не знаете. Я не мастер писать 100 томов макулатуры чтобы скрыть от Вас правду. Ценю своё время и предлагаю делать это Вам когда начнёте читать. (Тупой плагин подчёркивает все слова с правильно написанной буквой ё.) Я не предлагаю изобретать велосипедов и эти темы в топике автоматически флуд, - спросить можно развивать флуд не следует.
1. Давайте расскажем как сертифицируются программы на защиту данных в реальности.
2. Давайте поделимся опытом когда Вашу программу купило предприятей с более чем 100 пользователей.
3. Давайте щегольство понятиями типо криптостойкость считать фразами человека не знакомого с документами распорядка организации и нормами прав/наказаний.

Свой опыт начну в постах топика и соответственные реплики желаемо там. Делитесь своим опытом только при душевном расположении - вы плодите потенциальных конкурентов. Если фобиями не страдаете делитесь ибо то что Вы отдали вернётся к Вам. Думаю Манифест уже жирный. Го к дискурсии.

Добавлено:
Начну пожалуй из практики. Мне кажется если человек не знает какие данные требуют серьёзной защиты а это 99% читателей, то этот человек не знает что такое защита. Всем советую считать что Вы это знаете и читать дальше. В прошлый раз я лапухнулся перед директором предприятия где более 100 сотрудников, но они почему то купили нашу программу, непонятка. Ребяты во первых что вы защищаете? Защищать надо только деньги иначе исчите другую ветку для поддержания авторитета. Ладно расскажу как было.
У нас программка типа СРМ только расчитана идеально под менеджеров. Я тупой новый программист. До кучи ещё и сопроводиловка. Я написал в программе где адрес типо что заезд справо дирик полное гомно и ненавижу атомную войну. Я думал что когда распечатаю карточку клиента то получю всю инфу - я облажался фастреп настроен на другое поле - на автоматический адрес и никакой кастомной инфы. Директриса до этого задала свой вопрос о защите информации и я реально пытался объяснить что защиты вообще нет. Она почемуто ехидно мне намекнула что всё поняла, а потом они купили прогу на 200 юзеров. Давайте это возьмём в контрольную точку и дальше будем по правде, а не по понятиям недоступным для практического анализа. Вы знаете, я не удивлюсь утверждениям что в Московских институтах криптографии начнут изучать байты Васи программиста ктоторый шифровал свои собственные стихи и используют для этого компьютеры типо Вакс - гоняют без удержно терабайты информации в течении месяца. Без понимания базовых основ защиты данных слово криптостойкость полный ноль. Начнём с этого.

Спец по сертификации на защиту инфы провелял у нас прослушиваемость помещения. И не мудрено - в моих записях недельной давности часто есть такие записи которые я не могу понять даже если буду думать целый час над ними - контекст всегда ценен. Предлогаю перейти к методам.
Автор: delover
Дата сообщения: 13.03.2012 21:13
Далее будет обоснование утверждению о том что криптостойкость 0%. Но до этого ваши знания должны дорасти хотябы до теоретических знаний о безопасности данных.

Первым пунктом защиты от хаккеров является чёткое пониманите термина конфидециальность. Без владения этим понятием Вы овладеете наукой но заработаете 0 денег и заработаете геморой в придачу. Мне хочется реальных вопросов и наездов что я не прав. Чтобы перейти к более конкретным понятиям, но пока я в максимально сжатом виде успеваю дать Вам науку не прописанную в учебниках а подчерпнутую из трактатов Кулибина. Для затравки - умолял сломать мою программу кулхакеров в варезе руборда, предлагал деньги, но хаккеры отмазались. Думаю может быть интересно поговорить на эту тему?

Добавлено:
Свормировалась ещё одна мысль. До того как Вы ознакомитесь с законодательными документами о сертификации на безопасность данных слово криптоустойчивость это то же самое что число Pi сказанное папуасом. Я может быть грубо сазал, но после ознакомления с документами Вы скажете что мягко сказал.

1. Данные зашифрованные идеальными алгоритмами = потерянные данные, так же как ключи теряют. Если будет клиент недовольный тем что Вы его не спасли а он потелал Вас в ближайшее время уволят. Это реали России через которые прошол не только я, так что давайте начнёб беседу в пользу XOR алгоритмов и пиявок хаккерам.
2. Введём понятие - Астрономическая криптостойкость = Научная криптостойкость доказанная наукой. Это удобно бля бееседы и не нарушает канву.
3. Предлагаю Кулибина считать таким же учёным как и остальные. Из этого следующее.
4. Есть курсы по защите от нападений на улице - как и куда надо бить, рассказывать не буду, аналогичных курсов для программистов не существует - предлогаю открыть и изьясняться.
Автор: A1exSun
Дата сообщения: 14.03.2012 00:19
Моя глупая тема натолкнула?
Автор: karakurt2
Дата сообщения: 14.03.2012 02:23
Мне нравятся Ваши анекдоты.
Автор: delover
Дата сообщения: 14.03.2012 06:25
A1exSun
А она не глупая это даже можно доказать.

All - с чего появилась тема
Существует гипотеза, пока не обоснованная о следующем. Введём аксиоматическое положение о том что наша программа не доступна для хаккеров и даже недоступна для Московских институтов имеющих доступ к супер-компьютерам. Наша программка гоняет в каналы данные скрытые следующим образом.
1. Берём севен-зип с паралём 0 и опцией шифровать имена файлов.
2. Из архива вырезаем первые два байта 7z
3. Накладываем немного не тривиальный XOR - 1 байт xor 1, второй xor 2 и так до 256 потом снова.

Каковы шансы прослушивающих спецслужб типа частных подобрать раскодирующий алгоритм? Гипотеза утверждает что таких шансов 0. То есть итогом является то что архивирующий алгоритм суммированный с алгоритмом XOR является вполне криптостойким алгоритмом шифрования. Необходимо либо доказать либо опровергнуть гипотезу.

Добавлено:
добавлю - из разговоров в курилке слышал фразу - "да понятно что алгоритмы архивирования это то же самое что шифрование, кто же спорит?" но тут же спорят. Однако пока аргументов против моей гипотезы мало.

Добавлено:
Чтоб было поинтересней, допустим я гоняю базу FireBird 2.5 для репликации с вырезанными 4 первыми байтами и переименованную в файл "0.0". Она зашифрована алгоритмом приведённым выше. Репликацию проводит админ получивший по телефону инструкции и получивший программу через терминал.

Почему надо вырезать первые байты? Это основопологающие действия людей знакомых с понятием Идентификация. Есть псевдонаучная теория что достаточно вырезать первые байты и всё проканает, но это не правильно, так как могут догадаться по имени файла.
Автор: wasilissk
Дата сообщения: 14.03.2012 08:00
delover

Цитата:
Каковы шансы прослушивающих спецслужб типа частных подобрать раскодирующий алгоритм?

Шансы - 100%.
Вас испортила абстракция потенциальной осуществимости. При оценки криптостойкости системы, берется оценка самого слобого её звена. Этим звеном при использовании людских ресурсов будут людские ресурсы. Допустим вы перестанете быть неуловимым Джо для спецслужб (иначе с чего они вообще будут вас прослушивать), им будет достаточно одного факта, что вы от них что-то скрываете (сигналом для это послужит то, что вы какую-то фигню пересылаете по проводам непонятную).
Далее специалист отдела К, доктор медицинских наук, применяет научно доказанный терморектальный криптоанализ и поток ваш расшифровывается со скорость не менее 4.7 Гб/с.
Автор: delover
Дата сообщения: 14.03.2012 08:12

Цитата:
Допустим вы перестанете быть неуловимым Джо для спецслужб (иначе с чего они вообще будут вас прослушивать)

Ну Вы же портите гипотезу с самой головы тем что опровергаете аксиому.

Цитата:
Введём аксиоматическое положение о том что наша программа не доступна для хаккеров и даже недоступна для Московских институтов имеющих доступ к супер-компьютерам.

Без этого аксиоматического условия нет и самой гипотезы и просто нечего доказывать и опровергать.


Цитата:
При оценки криптостойкости системы, берется оценка самого слобого её звена. Этим звеном при использовании людских ресурсов будут людские ресурсы.

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

Добавлено:

Цитата:
Далее специалист отдела К, доктор медицинских наук

Кстати этот доктор видимо знаком с наукой Семиотика, в которой есть подраздел - Прагматика (польза по нашему). С точки зрения постановки задачи алгоритм шифрования одинакого полезен как и алгоритм архивирования+XOR. Однако если нам нравится Прагматика, то мы не можем не заметить преимуществ XOR. Даже если программист не имеет исходников программы то более вероятно что он востановит программу чем вспомнит какими ключами - паролями шифровал поток. Пароли чаще всего забываются чем что либо интересное и осмысленное. Мой метод так же имеет запас эффективности при криптодопиливании, например xor не от 1 до 256 а до 250.
Автор: wasilissk
Дата сообщения: 14.03.2012 08:50
delover
Вас не поймешь, то вам не нравится эта ваша астрономической криптостойкость, то внезапно на ней вы и концентрируетесь.
Дано, открытый канал данных, зашифрованный текст. Наверно во всех книгах по криптографии разобраны все возможные атаки на зашифрованный текст и возможные способы защиты в данном случае. Это практически идеальные условия для криптографа. Вы что-то хотите добавить нового?
Автор: delover
Дата сообщения: 14.03.2012 10:36
wasilissk

Цитата:
Это практически идеальные условия для криптографа. Вы что-то хотите добавить нового?

Да пока мне не докажут что во всех книгах криптографии разобраны способы как разархивировать алгоритмом deflate я буду считать что криптографы не получат исходных данных.

И даже скажу более - бесполезно потратят время.
ОБОСНОВАНИЕ:
1) Для оценки астрономической криптостойкости требуется ввести некоторое понятие.
2) Суммарная математическая работа по преобразованиям над данными для шифра и архивирования может быть сопоставлена количеству кода производящего преобразования над данными.
3) У архиваторов если брать современные байтов больше, и работают они медленнее за счёт величины пути процессора по байтам. Следовательно математическая сложность подбора математики обратных преобразований, по законам пропорций Выше у архиваторов нежели у имеющихся на сегодня алгоритмов криптования.
4) Современные алгоритмы шифрования исчисляются 100 лет на подбор, значит дешифровать архивацию методами криптографии уйдёт более 100 лет.
5) Следовательно по принципу актуальности данных они их вероятно получат а скорее всего даже не получат, но если получат то тогда когда данные будут никому не нужны.

Суммарную мат работу в количестве тиков процессора надо расписывать или она понятна?
Автор: wasilissk
Дата сообщения: 14.03.2012 10:57
delover

Цитата:
я буду считать что криптографы не получат исходных данных

Okay. Это ваше право.

Цитата:
Суммарную мат работу в количестве тиков процессора надо расписывать или она понятна?

Нет, спасибо, на сегодня мне уже достаточно.
Автор: ManHunter
Дата сообщения: 14.03.2012 11:08
А смысл расшифровывать трафик, который закодирован неизвестным алгоритмом, пусть даже банальным xor?
На исследование берется передающая программа и принимающая. Из нее узнается формат исходного файла, какие операции с ним проводятся, и все. Весь вопрос только в том, кто будет заинтересован в получении данных и какой под это будет выделен бюджет. Никто не будет напрягать институты с суперкомпьютерами, если можно устроить маски-шоу с временным изъятием техники, дать XXX$ младшему помощнику старшего эникейшика, чтобы он слил на флешку программу и/или базу, взломать сервер и слить оттуда нужные данные, купить копию такой же программы и разобрать ее, и т.п. Способов масса. Реальный мир, в отличие от виртуального, очень жестокий Повторюсь, все зависит от уровня заинтересованности и выделенного бюджета.
Автор: akaGM
Дата сообщения: 14.03.2012 11:11

Цитата:
Далее специалист отдела К, доктор медицинских наук, применяет научно доказанный терморектальный криптоанализ и поток ваш расшифровывается со скорость не менее 4.7 Гб/с.
+1!
Автор: delover
Дата сообщения: 14.03.2012 11:20
wasilissk
Ладно просто пока не забыл запишу два тезиса.

1) Хороший алгоритм шифрования должен обладать элементами перемешивания, так в общем рассказывают. Алгоритм deflate, на сколько я помню, в основе своей содержит перестановку порции байтов удобным для него способом. Это о том что перемешивание есть.

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

Итогом пока что является, что XOR + архиватор обладает большими криптостойкими характеристиками. Если декриптовать в конце концов заархивированное, то результат будет на 100% отличаться от исходных данных.
Автор: YuriyRR
Дата сообщения: 14.03.2012 15:13
И Опять сначала! Уже и в другой теме! Завязывайте. Идите книжки читать.
Баба Маша мне пароль оставила от ваших супер крипто прог на листочке под монитором и все электронные ключи на связке дала. Все бесполезно.
Автор: delover
Дата сообщения: 14.03.2012 18:32
YuriyRR
Вы не уловили мою мысль в предыдущих постах, прочитайте ещё раз, книги устаревают. Предлагаю купить у меня есть полное собрание сочинений Ленина - осваивайте на досуге.

ManHunter

Цитата:
На исследование берется передающая программа и принимающая.


Цитата:
Повторюсь, все зависит от уровня заинтересованности

Всегда можно отличить человека умеющего мыслить как отличный хаккер. Добро пожаловать в топик. Как сказал уважаемый karakurt2 (похоже встречал в варезе), как минимум Вы можете сдесь поржать, как максимум - натолкну на правильный ход мыслей. Тут история как с вирусами - вирусы нужны антивирусам и хаккеры нужны программерам. Без этого пропадает эстетика профессии про которую мы сейчас немного раскроем...

wasilissk

Цитата:
Okay. Это ваше право.

Ну если сам Василиск, контрибутор vdbi, дал добро будем теорему считать доказанной. Существуют условия когда XOR криптографически непобедим. Но воспользуемся новыми впечатлениями и поищем уязвимость. Есть ли условия когда XOR+архив это фуфло? Да я Вам сразу нарисую:
Задача. Майл клиент который принимает отправляет данные через майл почту. И надо всего лишь хранить пароли в INI файле. Кроме прагматических доказательств неуместности XOR+архив существуют эстетические. Не буду флудить эстетикой просто скажу - у меня рука не повернётся использовать XOR+архив и не потратить это время на работу с доказанными святой наукой методами, но главное дающими красивый код. Реально красивый. Алгоритмы криптования сохраняют индивидуальность. Индивидуальность самое святое понятие поборников Кулибина. А если вспомним что архивирование само по себе жирное, то вопрос иссякнет. Тут даже простой XOR без архивирования гораздо лучше. Но он к сожалению по тем же понятиям не кашерный. Да и фига ли сжимать 3 байта пароля + бла бла которую вы добавите для компенсации? Немного продвину мысль вперёд - выбор способа шиврования частично зависит от типов данных, это почти так же как у архивов - UPX лучше для EXE. Всё это я пока бездоказательно выдвинул, так как нет практической ценности это доказывать всем.

ИТОГ:
Криптостойкость менее важный фактор при выборе алгоритма шифрования, менее важный чем эстетический. Если будет доказано что воробьёв лучше бить атомными бомбами то в факторе появится коэффициент.

Добавлено:


Хочу подвести первую черту - один фьючерз,
Если программа существует в реальности на электронном носителе её криптостойкость 0%
Автор: wasilissk
Дата сообщения: 14.03.2012 18:48
delover

Цитата:
Ну если сам Василиск, контрибутор vdbi, дал добро будем теорему считать доказанной.

Мда, забавные у вас методы доказательства. Напомнило
Гоги: квадрат гыпатинузи равен сумми квадратов катитоф
Учиталь: Докажи!
Гоги: Вах! Мамой клянусь, да!
Я вам кстати добра не довал, у вас своего добра как я вижу навалом. Удачи.
Автор: delover
Дата сообщения: 14.03.2012 18:53
если программист существует то криптостойкость меньше чем 0.

Добавлено:
Что то ещё не дописал. Меня всегда удивляют люди типа YuriyRR - мне надо на улицу там мороз мне надо валенки а он предлагает книги почитать. Ну как его мама научила наверно. Тогда это хорошо - на улицу не пойду буду читать.
Автор: Molniev
Дата сообщения: 14.03.2012 20:41
delover
О чем вы вообще пишите? Какие то абстрактные споры. И к слову:

Цитата:
Немного продвину мысль вперёд - выбор способа шиврования частично зависит от типов данных, это почти так же как у архивов - UPX лучше для EXE. Всё это я пока бездоказательно выдвинул, так как нет практической ценности это доказывать всем.

О чем вы? Криптографически стойкий алгоритм сохраняет стойкость вне зависимости от того над какими данными он применяется.

Цитата:
Криптостойкость менее важный фактор при выборе алгоритма шифрования, менее важный чем эстетический. Если будет доказано что воробьёв лучше бить атомными бомбами то в факторе появится коэффициент.

Чё? Криптографическая стойкость это самый важный фактор при выборе алгоритма. Какая ещё эстетика? Данные либо защищены либо нет.

Цитата:
Если программа существует в реальности на электронном носителе её криптостойкость 0%

Я перечитал это предложение несколько раз, но понять его не смог. Начать можно уже с того, что криптографическая стойкость - это свойство алгоритмов, а не программ.
Автор: BorlandIMHO
Дата сообщения: 14.03.2012 20:43
ПрачЕтал. Бред...
Открытые (в смысле - доступные в исходных кодах) современные стандартные криптоалгоритмы обеспечивают вполне надёжное шифрование данных. Взлом зашифрованного криптоканала того же самого OpenVPN в отсутствие ключей шифрования - утопия, даже при наличии полного дампа сессии от подъёма канала до разрыва. Всё, что можно сказать по этому дампу о переданной информации - это приблизительный объём переданного...
Точно так же практически невозможно взломать шифрованный архив того же RAR при достаточной длине пароля (читай-ключа шифрования), составленного из случайных символов. Брутфорс штука хорошая, но при длине такого пароля, скажем, 64 символа (512 бит) - бессилен.
Так что основная проблема сокрытия информации шифрованием - это генерация и хранение ключей.
Автор: Molniev
Дата сообщения: 14.03.2012 20:55
BorlandIMHO
Согласен. Добавлю ещё, что помимо ключей важна корректная реализация алгоритмов.
Автор: delover
Дата сообщения: 14.03.2012 21:18
Molniev
BorlandIMHO
Я тут удалил текст, потому что история забавная...
Рассказываю я товарищу на улице историю про одного предпринимателя.
- Захожу к нему в кабинет смотрю сейф стоит посередине, на сейфе бумажка наклеена, на бумажке написано:
- Это сейф, пароль 12345.
- Я значит говорю предпринимателю, Вы мол не надёжно деньги прячете, смотрю на бумажку и думаю забавный пароль.
- Предприниматель мне и говорит - сейфы штука надёжная, я не про конкретный сейф а вообще.
- Ну ладно, я говорю, а вы когда уходите из кабинета дверь закрываете. Он отвечает
- Да зачем всё равно сейфы штука надёжная.
Поржали мы дальше про сейфы перетираем и тут откуда ни возьмись блондиночка. И говорит:
- А Вы бред какойто несёте, сейфы придуманы для надёжности, я не про конкретные сейфы а вообще.
Тут мне товарищь ))
- Хорошо хоть красивенькая.
Ну она и говорит
- Меня Юля завут.

Ну Юля конечно алгоритмы а не программы.
Автор: salexn1
Дата сообщения: 15.03.2012 13:38
delover
Вы мне напоминаете героя фильма: Елки-Палки
Он бегал с теорией государства, а вы открыли для себя оператор XOR и бегаете с топика в топик с идеей как-бы его применить.
Автор: delover
Дата сообщения: 15.03.2012 20:22
salexn1
Зачёт сразу. Только не забывайте - это повод для общения в котором выяснится что хаккеры умнее лохов программеров, но непонятно почему лохи станут умнее. Мне то хотелось бы этого, никого лично унижать не собираюсь, в том числе и хакеров, Бог мне диктует - так будет красивее и я говорю ну ладно. Пользоваться приёмами Малахова младшего не собираюсь.

All просто всегда надеюсь на адекватную реакцию
А получаю реакцию похоронную, все уже признали Кулибина а спустя 300 лет нашелся кто не признаёт. Программирование - прикладная наука не надо воображать себя принцессами. Вы программисты те же Кулибины, если не так займитесь вышиванием крестиком, больше пользы будет. До смешного уже хочу, архиватор + хор это чтобы данные тестировали на криптоалгоритм хотябы неделю. Принесёт мне это сказочное удовольствие несравнимое с зарплатой за месяц. Это было отступление потому что я почти его получил.



Добавлено:
Согнута струя моя
И я не чую нифуя
Что мне делать - как мне жить
Как жону свою любыть.
Автор: ItsJustMe
Дата сообщения: 15.03.2012 21:16
delover
Я главного в речах не понял - куда деньги отсылать и за что? МПХ вы увеличить не предлагаете, от налогов уйти не предлагаете, а что предлагаете? Я, вот, к примеру - лох, и с радостью отдам первому попавшемуся говорливому мошеннику деньги. Но даже я не понял, за что и куда. А тут программеры сидят, люди умные и суровые. Если вы даже простого лоха развести не способны, то чего же вы здесь ловите?.. Загадко, аднака...
PS: Хотя одна догадка у меня есть У вас просто словесный понос, а я сдуру скрытый смысл ищу. Видимо, надо быть проще и люди к вам потянутся меньше читать о теории заговора...
Автор: delover
Дата сообщения: 15.03.2012 22:49
ItsJustMe
А Вы Юля ну добро пожаловать. Если в Ваше сообщение добавить аналитику то можно увидеть и отрицательный приход и соответственно отрицательное наличие. Поменяйте местами приход с расходом и уберите минус. Как прабабушка учила - не из дома надо таскать а в дом. В пустой программке на дельфи в коде помечены куски байтов именами юнитов которые никто за мои 5 лет не переименовывал, среди них встречаются имена библиотек шифрования, ради любопытства ставил туда брейкпоинт в слепую, потом находил от куда пришло, потом тупо читал стек и воспроизводил в другой программе. Более двух дней веселье не занимает. Про понос это пожалуйтса тем кто говорит о криптостойкости 100 лет, в моих условиях криптостойкость обычно 1 день. Присутствие байтов известных библиотек вычисляется так же легко как вирусы. Если программа не прошита чемто типа аспака посерьёзнее, говорить об криптостойкости понос похлещще.


Цитата:
А тут программеры сидят, люди умные и суровые.

Да Вы наверно шутите. Хотябы одно положение которое я не доказал? Я не спешу, матрёшка например состоит из задачи открыть сначала первую матрёшку потом вторую а не наобарот, поменяйте приход с расходом.
Автор: akaGM
Дата сообщения: 15.03.2012 22:56
нда...
Автор: delover
Дата сообщения: 16.03.2012 05:56
Так чтобы более понятней были метафоры - сейф=алгоритм криптовки. Бумажка на сейфе это отпечаток известных библиотек шифрования. Когда мы выбираем XOR, для меня сложность взлома вашей программы будет составлять более 2х недель. Заметьте мы не стали платить за СтарФорс и заставили хаккера требовать пол месячной зарплаты программера. Если свести баланс то получается примерно заработали месячную зарплату. Надеюсь что более понятно стало что я пишу. Кулибинские алгоритмы шифровки так же идеальны.

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

Я тогда буду переходить к прививкам от взлома, так как если был выбран СтарФорс, моя тема мало чем поможет.

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

Добавлено:
ЗЫ
если kernel32.dll не лежит в положенной системной папке а рядом с программой, что бывает черезвычайно редко можно даже не задумываться что это пустышка. Есть и другие методы, например найти ещё один правильный кернел в памяти и так далее. Если хаккер умудрился заставить весь Windows работать через свой кернел то скорее всего не поможет никакая защита вообще.
Автор: wasilissk
Дата сообщения: 16.03.2012 07:40
delover

Цитата:
Первый метод защиты от взлома - динамическая загрузка адресов DLL функций. Например достаточно переписать файловый поток на свой заменив вызовы системных функций на динамически загруженные. И вот шифрованный поток уже гораздо сложнее поймать.

С чего это вдруг? При динамической загрузке они будут точно такие же как и при статической.
Автор: delover
Дата сообщения: 16.03.2012 10:14
wasilissk
При динамической загрузке
1. Мне в этом случае нравится HIEW больше, когда я смотру ассемблерный дамп он сразу подписывает

Цитата:
CALL $AA0011 - ; kernel32.TerminateProcess

Да и отладчики подписывают, очень удобно чтобы поставить сюда брейкпоинт.
2. Легко найти все точки где стоит этот вызов в процессе. Так делает метод
TJclPeMapImgHooks.HookImport. То есть все вызовы CALL $AA0011 я могу переопределить на свои собственные, даже не крякая программу.
3. при статической, загрузке все такие методы прописываются в таблице импорта. Например меня могут удивить такие функции как VirtualProtect в импорте программы, который естественно необходим если программа собирается защищаться от хаккеров. Функции IsDebugAttached и так далее при просмотре импорта взламываемой программы всегда вызовут мой живейший интерес.
4. При динамической загрузке невозможен Hook.
Автор: wasilissk
Дата сообщения: 16.03.2012 10:45
delover

Цитата:
1.

И при чем же тут динаическая загрузка?

Цитата:
2. ... CALL $AA0011

Это как раз статическая загрузка. Вообще не понял в какую сторону заангажирован этот аргумент.

Цитата:
3.

Ага, а при динамической, хакер сразу как бы забывает, что есть такая функция и её не проверяет ни в коем случа. Хакер же тупой читает таблицу импорта, открывает msdn и смотрит, а что же такого делает этот самый VirtualProtect. Ну-ну.

Цитата:
4.

Hook на что невозможен? На вызов API функций? Уверены?

Все таки ближе к телу, т.е. к вашему потоку. Я хочу его выцепить. Знаю что там вызываются, либо ReadFile, либо WriteFile, cтавлю бряки в kernel32.dll на эти функции в четыре щелчка. Каким образом вам поможет ваше переписывание вручную потока с динамическим вызовом функций?

Страницы: 12

Предыдущая тема: Шифрование с помощью XOR - криптоанализ


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.