первое вхождение искомой последовательности в образе диска
Листинг 8.2. Второе вхождение искомой последовательности в образе диска
00010370: 01 00 00 00 00 01 91
63 ¦ CD 36 00 00 36 CD 63 67 O OСc=6 6=cg
00010380: 06 1D 17 0D 0A 28 0C 00 ¦ 00 00 01 00 00 01 32 00 ¦-¦d0(+ O O2
00010390: 30 00 31 00 20 00 2D 00 ¦ 20 00 50 00 65 00 72 00 0 1 - P e r
000103A0: 73 00 6F 00 6E 00 61 00 ¦ 6C 00 20 00 4A 00 65 00 s o n a l J e
000103B0: 73 00 75 00 73 00 2E 00 ¦ 6D 00 70 00 33 00 3B 00 s u s . m p 3 ;
Листинг 70 второе вхождение искомой последовательности в образе диска
Искомое значение действительно присутствует в образе, причем не в одном, а в двух… нет, даже в четырех экземплярах! Нет, это не чертовщина — – все так и должно быть. Современные лазерные диски содержат две файловых системы: одна из которых —– ISO-9660 —– записывается на диск исключительно для его совместимости с устаревшим программным обеспечением, ограничивающим максимальную длину файла одиннадцатью символами (восемь из которых приходятся собственно на само имя, а оставшиеся три —– на расширение). Современное программное обеспечение работает с более "продвинутыми" файловыми системами к которым принадлежит и файловая система Joliet Джульета (ДжульеттаJoliet), разработанная компанией Microsoft. Говорите, "только Ромео для полноты компании не хватает"? А ведь файловая система Romeo Ромео (РомеоRomeo) действительно есть и разработана она компанией Adaptec. К сожалению, этот "Ромео" не получил большого распространения и скоропостижно "скончался", так что Joliet (Джульетта) вынуждена оставаться лась в одиночестве.
Но довольно романтики, возвращаемся к делу. Заботиться о синхронизации обоих файловых систем в общем-то и необязательно, т. к. операционная система Windows "видит" только Joliet Джульету и игнорирует ISO-9660, а MS-DOS поступает с точностью до наоборот. Поэтому, если мы увеличим длину файла в JolietДжульете, но "забудем" внести соответствующее изменения в ISO-9660 (а некоторые разработчики защит именно так и поступают!), Windows не заподозрит в этом и тени обмана.
Вот хакеры —– другое дело! Оригинальные длины файлов, оставленные в ISO-9660, значительно упрощают задачу взломщика и потому оставлять их там ни в коем случае не стоит! К тому же, существуют драйвера, позволяющие вручную выбирать какую из имеющихся файловых систем следует монтировать. Так что не будем лениться и скорректируем оба значения сразу, изменив два старших байта с "36 00" на "FF 66" (естественно, вы можете предпочесть и другое значение). Когда будете это делать обратите внимание на двойное слово "00 36 CD 63" —– это тоже длина файла, но записанная в "противоестественном" для IBM PC порядке. Здесь младший байт располагается по большему адресу. Адрес стартового сектора файла так же записан в двух вариантах. Очевидно, такая схема представления информации выбрана по соображениям переносимости и каждая платформа вправе выбирать наиболее естественный для нее порядок байтов, однако, не факт, что операционная система Windows выберет вариант "младший байт по меньшему адресу". Все решает файловый драйвер, а он в зависимости от особенностей реализации может работать с любым из этих полей. Поэтому, оба этих поля всегда должны быть согласованы.
Теперь исправленный (в смысле искаженный) ISO-образ можно смело записывать на диск CD-R/CD-RW диск или смонтировать образ на виртуальный CD-привод (для этого вам понадобиться Alcohol 120% или его аналоги). Даем команду "DIR" и смотрим (листинг 8.3).:
Листинг 8.3. Размер файла Personal Jesus.mp3 умышленно искажен
>
dir N:\Depeche Mode
Том в устройстве N имеет метку 030706_2038
Серийный номер тома: 61A1-A7EE
Содержимое папки N:\Depeche Mode
06.07.2003 21:56 <DIR>
.
06.07.2003 21:56 <DIR>
..
01.01.1601 04:00 1 728 040 291
01 - Personal Jesus.mp3
30.06.2003 00:11 3 574 805 02 - See You.mp3
30.06.2003 00:12 3 472 405 03 - Strangerlove.mp3
30.06.2003 00:12 3 718 165 04 - Enjoy The Silence.mp3
30.06.2003 00:13 2 956 643 05 - The Meaning Of Love.mp3
30.06.2003 00:14 3 820 565 06 - Master and Servant.mp3
30.06.2003 00:15 3 066 149 07 - Never Let Me Down Again.mp3
30.06.2003 00:16 3 806 772 08 - Its Called a Heart.mp3
30.06.2003 00:16 3 813 460 09 - Little 15.mp3
30.06.2003 00:17 3 574 805 10 - Everything Counts.mp3
30.06.2003 00:18 3 687 236 11 - People Are People.mp3
30.06.2003 00:19 4 916 036 12 - The Thing You Said.mp3
30.06.2003 00:20 4 182 100 13 - Agent Orange.mp3
30.06.2003 00:21 4 585 012 14 - World in my Eyes.mp3
30.06.2003 00:22 3 646 276 15 - Behind The Wheel.mp3
30.06.2003 00:22 3 049 012 16 - Black Celebration (live).mp3
30.06.2003 00:23 3 800 085 17 - Nothing.mp3
30.06.2003 00:25 7 151 700 18 - Bonus (unnamed).mp3
18 файлов 1 794 861 517 байт
2 папок 0 байт свободно
Листинг 71 размер файла "Personal Jesus.mp3" умышленно искажен путем
Вот это да! Размер файла увеличился до 1 .728 .040 .291 байт (см. выделенную полужирным шрифтом строку листинга), что более чем в два с половиной раза превышает объем всего лазерного диска. А еще говорят, что часть не может быть больше целого! Естественно, попытка скопировать файл на жесткий диск винчестер заканчивается провалом и приходится искать обходные пути. Будем исходить из того, что файлы на диске располагаются последовательно, т. е. за последним сектором одного файла, непосредственно следует стартовый сектор следующего. А, поскольку, стартовые сектора всех файлов нам известны, определение номеров последних секторов для всех файлов, за исключением самого последнего, не составит никакого труда.
Скопируем ISO-образ защищенного диска в файл и рассмотрим его каталог еще раз (листинг 8.4).:
Листинг 8.4. Подследственный фрагмент "препарируемого" образа файла
0000E040: 00 01 01 01 54 00 94 01 ¦ 00 00 00 00 01 91 63 CD OOOT Ф¦ OСc=
0000E050: FF 66 66 FF CD 63 00 00 ¦ 00 00 00 00 00 00 00 00 ff =c
0000E060: 01 00 00 01 32 00 30 00 ¦ 31 00 20 00 2D 00 20 00 O O2 0 1 -
0000E070: 50 00 65 00 72 00 73 00 ¦ 6F 00 6E 00 61 00 6C 00 P e r s o n a l
0000E080: 20 00 4A 00 65 00 73 00 ¦ 75 00 73 00 2E 00 6D 00 J e s u s . m
0000E090: 70 00 33 00 3B 00 31 00 ¦ 46 00 6B 08 00 00 00 00 p 3 ; 1 F k•
0000E0A0: 08 6B 15 8C 99 00 00 99 ¦ 8C 15 67 06 1D 17 0B 1C •k§МЩ ЩМ§g¦-¦>L
0000E0B0: 0C 00 00 00 01 00 00 01 ¦ 24 00 30 00 32 00 20 00 + O O$ 0 2
0000E0C0: 2D 00 20 00 53 00 65 00 ¦ 65 00 20 00 59 00 6F 00 - S e e Y o
0000E0D0: 75 00 2E 00 6D 00 70 00 ¦ 33 00 3B 00 31 00 50 00 u . m p 3 ; 1 P
Листинг 72 подследственный фрагмент препарируемого образа файла
Наименьший номер стартового сектора файла, следующий за сектором 0191h, равен 086Bh. Таким образом, файл "01 – – Personal Jesus.mp3" не может содержать более 086Bh -? 0191h === 6DAh секторов или 1754 * 2048 === 3 .592 .192 байт. Конечно, это несколько завышенная оценка и действительный размер файла на 1,5полтора Ккилобайта короче, но такое расхождение уже не критично. Большинство мультимедийных файлов будут вполне нормально обрабатываться даже при наличии некоторого количества постороннего "мусора" на "хвосте". Исправив образ файла, запишем его на диск или просто усечем файл до необходимых размеров с помощью любой подручной утилиты типа "Добермана Пинчера" ("Pinch of File").
А что делать, если вас не устраивает столь низкая стойкость подобной защиты? Ну… кое-что вы можете сделать.
Например, уменьшить стартовые сектора некоторых файлов, "убивая тем самым сразу двух зайцев". Во-первых, файл с некорректно заданным сектором уж точно не будет нормально обрабатываться ассоциированным с ним приложением (что и не удивительно, ведь действительное начало файла теперь окажется глубоко в его середине), во-вторых, алгоритм определения оригинальных длин по разнице соседних стартовых секторов даст глубоко неверный результат и восстановленный файл окажется обрезанным.
Защитный механизм, "знающий" на сколько секторов сдвинуто действительное смещение файла относительно его начала, должен либо переместить файловый указатель вызовом функции SetFilePointer, либо "проглотить" "мусорные" данные с помощью функции ReadFile. Оба способа практически равнозначны и каждый из них имеет свои сильные и слабые стороны. Функция SetFilePointer работает значительно быстрее, но слишком заметена (для хакеров), напротив, с вызовом функции ReadFile еще предстоит разобраться какие данные он читает —– значимые или нет.
Рассмотрим, как выглядит процесс взлома на практике. Поскольку, писать полноценный MP3-плейер мне было откровенного лениво (да и места он бы занял немеряно), то вся обработка данных сводится к выводу оригинального содержимого файла на экран (листинг 8.5). Перед первым запуском программы, стартовый сектор защищенного файла должен быть уменьшен на величину _NSEC_, а размер увеличен по меньшей мере на 2048*_NSEC_ байт, верхнего же ограничения на максимальную длину нет (все 32-бита поля длины — ваши).
Листинг 8.5. [crackme.27AF7A2Dh] Демонстрация обработки файлов с искаженными атрибутами стартового сектора и длины
/*----------------------------------------------------------------------------
*
* crack me 27AF7A2D
* =================
*
* демонстрационный пример обработки файлов с умышленно уменьшенным номером
* номером стартового сектора и увеличенной длиной; позиционирование файлового
* указателя осуществляется вызовом функции fseek, потому этот crackme очень
* очень легко взломать (см. так же ..... - как более стойкий пример реализации
* реализации той же защиты)
*
* Build 0x001 @ 02.07.2003
----------------------------------------------------------------------------*/
#include <stdio.h>
// настройки программы
// ===================
// имя открываемого файла (если защита находится на CD, то полный путь к файлу
// очевидно указывать не обязательно)
#define _FN_ "M:\\Depeche Mode\\01 - Personal Jesus.mp3"
// количество секторов на которые смещено начало файла
#define _NSEC_ 4
// оригинальный размер файла
#define _FSIZ_ 3591523
// размер пользовательской части сектора
#define SECTOR_SIZE 2048
// ширина экрана в символах (нужна для вывода дампа)
#define _SCREEN_LEN_ 80
// размер обрабатываемого блока
#define BLOCK_SIZE 0x666
// поиск минимума двух чисел
#define _MIN(a,b) ((a<b)?a:b)
// ВЫВОД HEX-ДАМПА НА ЭКРАН
//-------------------------
// src - указатель на выводимые данные
// n - кол-во выводимых на экран байт
print_hex(unsigned char *src, int n)
{
int a; static p = 1;
for (a=1; a <= n; a++)
printf("%02x%s",src[a-1],(p++%(_SCREEN_LEN_/3-1))?" ":"\n");
}
main()
{
int a;
FILE *f;
long p = _FSIZ_;
char buf[BLOCK_SIZE];
// TITLE
fprintf(stderr, "crackme 27af7a2d by Kris Kaspersky\n");
// пытаемся открыть файл
if ((f = fopen(_FN_, "rb")) == 0)
{
fprintf(stderr, "-ERR: can not open %s\n",_FN_);
return -1;
}
// пропускам _NSEC_ лишних секторов, находящихся в начале файле
fseek(f, _NSEC_*SECTOR_SIZE, SEEK_SET);
// читаем файл блоками, тщательно следя за тем, чтобы не вылететь
// за пределы его оригинального размера
while(p)
{
// внимание! для обработки файлов с искаженным размером категорически
// не рекомендуется использовать функцию fgetc, поскольку в большин-
// стве своих реализаций она обрабатывает файл не байтам, но блоками
// заранее неизвестного размера. Т.е. она осуществляет прозрачную
// буферизацию ввода, опираясь на установленный размер файла как на
// эталонный. Если же установленный размер файла искажен, то нет
// никаких гарантий, что функция fgetc не залезет за пределы диска
// со всеми отсюда вытекающими последствиями (особенно это вероятно,
// если обрабатываемый файл - последний на лазерном диске), так что
// используйте fread, а еще лучше ReadFile, который уж точно не
// полезет в пекло поперед батьки
fread(buf, 1, a = _MIN(p,BLOCK_SIZE), f);
// читаем очередной блок
print_hex(buf,a);
p-= a // выводим его на экран
}
}
Листинг 73 [crackme.27AF7A2Dh] Демонстрация обработки файлов с искаженными атрибутами стартового сектора и длины. Перед первым запуском программы, стартовый сектор защищенного файла должен быть уменьшен на величину _NSEC_, а размер увеличен по меньшей мере на 2048*_NSEC_ байт, верхнего же ограничения на максимальную длину нет (все 32-бита поля длины – ваши).
Обнаружив, что основные атрибуты файла искажены (то есть файл попросту не читается), хакер очевидно захочет определить смещение первого действительного байта и оригинальный размер файла.
Применим отладчик Soft-Ice. "… Винии поплевал на лапки для храбрости и набрал заветную команду soft-ice." (почти по Щербакову)(листинг 8.6).
Листинг 8.6. Протокол работы с Soft-Ice
:bpx CreateFileA ; ставим точку останова на CreateFileA
:x ; выходим из айса
…
Break due to BPX KERNEL32!CreateFileA (ET=3.37 seconds)
; отладчик всплывает, значит, CreateFileA кем-то только что была вызвана
; но вот кем? пытаемся определить это по имени открываемого файла
:d esp->
4 ; смотрим первый слева аргумент, передаваемый функции
0010:0040706C 4D 3A 5C 44 65 70 65 63-68 65 20 4D 6F 64 65 5C M:\Depeche Mode\
0010:0040707C 30 31 20 2D 20 50 65 72-73 6F 6E 61 6C 20 4A 65 01 - Personal Je
0010:0040708C 73 75 73 2E 6D 70 33 00-4D 3A 5C 44 65 70 65 63 sus.mp3.M:\Depec
; ага! это как раз то что нам нужно!
:p ret ; выходим из функции
:? Eax ; подсматриваем значение дескриптора открытого файла
00000030 0000000048 "0" ; дескриптор равен 0x30 (или 48 в десятичной нотации)
:bpx SetFilePointer if (esp->
4 == 0x30);
:bpx ReadFile if (esp->
4 == 0x30)
; устанавливаем точки останова на основные файловые функции SetFilePointer и ReadFile,
; ReadFile, заставляя отладчик всплывать тогда и только тогда, когда им передается
; "наш" дескриптор! (специальное замечание для разработчиков защиты: господа,
; давайте же, право, себя так легко обмануть! открывайте файл несколько раз подряд и
; и попеременно работайте с ним через различные дескрипторы, - это сильно затрудняет
; затрудняет анализ)
:x ; выходим из отладчика
…
Break due to BPX KERNEL32!SetFilePointer IF ((ESP->
4)==0x30) (ET=76.19 microseconds)
; это сработала точка останова на SetFilePointer, теперь нам необходимо подсмотреть
; значение offset на которое смещается указатель и origin – чтобы определить
; относительно какой части файла осуществляется отсчет
:? esp->
8 ; смотрим второй слева аргумент функции
00002000 0000008192 " " ; указатель смещается на 0x2000 байт относительно…
:? esp->
0C ; смотрим третий слева аргумент функции
00000000 0000000000 " " ; …относительно начала файла (SEEK_SET)
:p ret ; выходим из отладчика
…
; больше функция SetFilePointer не вызывается, но зато наблюдается многократные
; вызовы функции ReadFile. Для анализа защитного кода мы не будем давать P RET
; (как это рекомендуют делать некоторые хакерские руководства). Ведь ReadFile
; скорее всего вызывается не напрямую, а из библиотечной функции-обертки,
; анализ которой нам ничего не даст. Лучше посмотрим стек вызовов…
…
:stack ; смотрим стек вызовов
12F8C8 401E1C KERNEL32!ReadFile
12F8F8 4010E5 crackme!.text+0E1C
12FFC0 77E87903 crackme!.text+00E5
12FFF0 0 KERNEL32!SetUnhandledExceptionFilter+005C
; адрес 55E87903h очевидно принадлежит недрам операционной системы и потому нам
; не интересен, адрес 401E1Ch (адрес возврата из ReadFile) там как же неинтересен,
; поскольку, как мы уже и говорили, скорее всего принадлежит библиотечной функции-
; обертке, а вот на адрес 4010E5h имеет смысл взглянуть:
:u 4010E5
001B:00401072 MOV EDI, 36CD63 ; EDI := 36CD63
001B:004010C8 CMP EDI,00000666 ; \ ß (1)
001B:004010CE MOV ESI,EDI ; +- ESI := _min(0x666, EDI)
001B:004010D0 JL 004010D7 ; +
001B:004010D2 MOV ESI,00000666 ; /
001B:004010D7 PUSH EBX ; …
001B:004010D8 PUSH ESI ; кол-во читаемых элементов
001B:004010D9 LEA EAX,[ESP+14] ; получаем указатель на буфер
001B:004010DD PUSH 01 ; размер одного элемента
001B:004010DF PUSH EAX ; передаем указать на буфер
001B:004010E0 CALL 00401141 ; эта функция вызывает ReadFile
001B:004010E5 LEA ECX,[ESP+1C] ; получаем указатель на буфер
001B:004010E9 PUSH ESI ; …
001B:004010EA PUSH ECX ; …
001B:004010EB CALL 00401000 ; обрабатываем прочитанные данные
001B:004010F0 ADD ESP,18 ; вычищаем ненужные аргументы из стека
001B:004010F3 SUB EDI,ESI ; EDI := EDI - _min(0x666, EDI)
001B:004010F5 JNZ 004010C8 ; мотаем цикл, пока есть что обрабатывать (1) à
001B:004010F7 POP ESI ; …
; изучение окрестностей адреса 4010E5 позволяет за считанные минуты восстановить
; алгоритм обработки файла. файл читается кусками по 0x666 байт до тех пор пока
; этих байт не наберется ровно 0x36CD63 (или 3.591.523 в десятичной нотации)
Листинг 74 протокол работы с soft-ice
Таким образом, после открытия файла его указатель смещается вперед на 0x2000 байт (4 сектора), а затем из файла считывается 3 .591 .523 байт данных, после чего его обработка прекращается. Следовательно, защищенный файл может быть восстановлен так…
Попробуйте его проиграть каким ни будь MP3-плейером. Если все было сделано правильно, то вы окунетесь в ритмичные звуки Depeche Mode, не омраченные более никакими защитами! Под такую музыку очень хорошо заниматься усилением защитных механизмов, а усиливать здесь есть чего!
"Хитрая" обработка защищенных файлов подразумевает использование как минимум трех дескрипторов для каждого файла: два из них обрабатывают действительно полезные данные, а третий "замысловато пляшет" по файлу, читая бессмысленный "мусор". Этот "мусор" передается громоздкой и жутко запутанной процедуре, выполняющий сложные, но реально никак не используемые вычисления. "Скормив" такой процедуре первые _NSEC_ секторов защищенного файла, мы создадим обманчивую видимость, что обработка файла начинается с его начала (ну… или почти начала, разработчику защиты ничего не стоит переместить указатель на любую понравившуюся ему позицию).
Реально используемые дескрипторы должны открываться после возращения "подсадного", т. к. большинство хакеров отслеживают лишь первый вызов функции CreateFileA, открывающийоткрывающей заданный файл, и игнорируют все остальные (многим просто не приходит с голову, что один и тот же файл может открываться дважды).
Позиционирование на первый значимый байт лучше всего осуществлять не функцией SetFilePointer, а путем чтения "мусорных" данных с последующей имитацией их обработки. В грамотно сконструированной защите определить где кончается мусор и начинаются действительно значимые данные очень и очень сложно. Однако, и запрограммировать такую защиту нелегко (а ведь ее еще и отлаживать придется!), поэтому для простоты можно ограничиться тем, что начало значимых данных совпадает с первым байтом очередного читаемого блока.
Оригинальную длину файла хранить в виде константы крайне нежелательно, т. к. при анализе программы все константы сразу же бросаются в глаза и нужное значение быстро находится даже тупым перебором (большинство программ содержат не так уж много констант, соизмеримых по величине с длинами обрабатываемых файлов). Храните не длину файла, ано длину его "хвоста", т. е. остаток, полученный от деления оригинальной длины на размер обрабатываемых блоков.
Естественно, размер блоков и их количество блоков так же придется где-то хранить, но… проанализировать взаимосвязь трех констант значительно труднее одной!
Учитывая все вышесказанноеранее сказанное, мы сможем значительно усилить нашу защиту. Один из вариантов ее реализации может выглядеть, например, так как показано в листинге 8.7.:
Листинг 8.7. [crackme.CEE99D84h.c] Программная реализация защитного механизма, основанного на искаженном оглавлении диска
// размер "хвоста" последнего блока
#define TAIL_SIZE (_FSIZ_ % BLOCK_SIZE)
// кол-во целых блоков
#define N_BLOCKS (_FSIZ_ / BLOCK_SIZE /2)
// ХОЛОСТАЯ ОБРАБОТКА ДАННЫХ
// -------------------------
// желательно сделать эту функцию как можно более сложной и запутанной,
// чтобы факт ее холостой работы был не так очевиден
threshing(unsigned char *src, int n)
{
int a, sum=0;for (a = 0; a< n; a++) sum += src[a]; return sum;
}
main()
{
int a = 0;
long p = _FSIZ_;
FILE *f_even, *f_uneven, *f_threshing;
char buf[BLOCK_SIZE + (_NSEC_*SECTOR_SIZE)];
// TITLE
fprintf(stderr, "crackme 27af7a2d by Kris Kaspersky\n");
// пытаемся открыть файл
// f_threshing лучше всего открывать первым, т.к. первый же встретившийся
// хакеру вызов CreateFileA должен давать "подсадной" дескриптор
if ( ((f_threshing = fopen(_FN_, "rb")) == 0) ||
((f_even = fopen(_FN_, "rb")) == 0) ||
((f_uneven = fopen(_FN_, "rb")) == 0))
{ fprintf(stderr, "-ERR: can not open %s\n",_FN_);
return -1;}
// устанавливаем f_even
fread(buf, 1, _NSEC_*SECTOR_SIZE, f_even);
// имитируем пропуск NSEC*SECOR_SIZE/2 байт (вдруг хакер на это купится?)
// на самом же деле, все NSEC*SECTOR_SIZE первый байт файла идут в муор-
// ное ведро
threshing(buf + _NSEC_*SECTOR_SIZE/2,_NSEC_*SECTOR_SIZE/2);
// устанавливаем f_uneven
fread(buf, 1, _NSEC_*SECTOR_SIZE+BLOCK_SIZE, f_uneven);
// имитируем пропуск NSEC*SECOR_SIZE/3 байт
threshing(buf + _NSEC_*SECTOR_SIZE/3, 2*_NSEC_*SECTOR_SIZE/3+BLOCK_SIZE);
// устанавливаем threshing, пуская хакера по ложному следу
fseek(f_threshing,_NSEC_*SECTOR_SIZE/4,SEEK_SET);
// читаем файл блоками, тщательно следя за тем, чтобы не вылететь
// за пределы его оригинального размера
for (a=0; a < N_BLOCKS; a++)
{
// читаем данные в холостую
fread(buf, 1, BLOCK_SIZE, f_threshing);
threshing(buf,BLOCK_SIZE);
// читаем четный действительный блок
fread(buf, 1, BLOCK_SIZE, f_even);
print_hex(buf,BLOCK_SIZE);
// пропуск нечтного блока для дескрпитора f_even
fread(buf, 1, BLOCK_SIZE, f_even);
threshing(buf,BLOCK_SIZE);
// читаем нечетный действительный блок
fread(buf, 1, BLOCK_SIZE, f_uneven);
print_hex(buf,BLOCK_SIZE);
// пропуск уже четного блока для дескрпитора f_uneneven
fread(buf, 1, BLOCK_SIZE, f_uneven);
threshing(buf,BLOCK_SIZE);
}
// дочитываем хвост
fread(buf, 1, TAIL_SIZE, f_even);
print_hex(buf, TAIL_SIZE);
}
Листинг 75 [crackme.CEE99D84h.c] программная реализация защитного механизма, основанного на искаженном оглавлении диска
Попробуйте взломать эту защиту. Что, не получается? Попытка отследить вызовы файловых функций SetFilePoiner и ReadFile ничего не дает, т. к. данные считываются глубоко нелинейным образом и способов быстрого отделения "зерен" от "плевел" здесь не существует. Такие защиты вообще не "ломаются" в отладчике, —– тут требуется помощь дизассемблера, но и с дизассемблером на скорый успех рассчитывать не приходится. Сложность и запутанность алгоритма обработки данных значительно усложняет анализ программы и на определение действительных границ файла даже у профессионала может уйти несколько часов (а в некоторых случаях и дней!). По соображениям экономии места дизассемблерные листинги и описание процесса взлома здесь не приводятся, поскольку в них нет ничего интересного —– просто тупая рутина и все. Единственная зацепка —– функция Threshing, имитирующая обработку данных. Как только хакер поймет, что результаты ее работы никак не используются в программе, он тут же продвинется далеко вперед. Контрольные точки останова на чтение/записи памяти позволяют быстро и элегантно определить: происходит ли обращение к заданным ячейкам или нет. Короче говоря, нет ничего тайного, что при помощи отладчика Soft-Ice и дизассемблера IDA Pro не стало бы явным…
