Бинарный файл
В информатике двоичный файл — это файл, который не является текстовым файлом . Многие форматы двоичных файлов хранят часть своих данных в виде текста (серии символов ), а остальные используются для интерпретации, форматирования или отображения этого текста.
По расширению языка мы называем «двоичным» любой файл, который не может быть интерпретирован в виде текста: изображение, звук или даже другой сжатый файл. Это также термин, специфичный для информатики, где мы начинаем с исходного кода (текста) для создания программного обеспечения в форме исполняемого файла (двоичного).
Резюме
- 1 Структура
- 2 Файлы и двоичные файлы
- 2.1 Проблема
- 8.1 Связанные статьи
- 8.2 Внешние ссылки
Состав
Двоичный файл состоит из серии байтов, каждый из которых состоит из 8 бит . Каждый файл структурирован в соответствии с определенным форматом, позволяющим его интерпретировать: файл, содержащий программное обеспечение, может быть запущен операционной системой , изображение может отображаться на экране.
Двоичные файлы обычно содержат заголовок для определения их формата. Этот заголовок начинается (или содержит) серию текстовых или двоичных символов, однозначно идентифицирующих структуру других данных. Эта последовательность называется «подпись» или «магическое число». Например, формат изображения GIF , широко используемый на веб- страницах , всегда начинается с текста «GIF87a» или «GIF89a» в зависимости от версии формата.
Файл, не содержащий заголовка или не идентифицируемый, называется «сырым». Затем он идентифицируется своим расширением и может хранить данные в частном формате, известном только исходному или получателю, например, данные с датчиков: термометров, микрофонов, сейсмографов. Расширение «.bin» часто используется по умолчанию и никоим образом не определяет содержимое такого файла: оно может хранить для видеоигры целый ряд элементов (изображений, звуков), иногда сжатых или даже зашифрованных.
Файлы отпечатков памяти содержат моментальный снимок, внутренняя структура которого не обязательно должна быть известна или чья структура не имеет отношения к конечной утилите файла (являясь только копией файлов «как есть». Данные для хранения / использования). Это относится, например, к так называемым файлам «ROM», предназначенным для аппаратных эмуляторов (обычно это файлы, содержащие отпечаток памяти электронных картриджей для игровых консолей и предназначенные для программных эмуляторов, работающих на компьютере или на компьютере. Другое. игровые приставки).
Файлы и двоичные файлы
По определению файл — это контейнер информации (например, файл библиотеки или даже книга и т. Д.). Современные технологические приложения информатики, в основном основанные на электронике, использование двоичной системы счисления в настоящее время в основном используется для представления (обработки, хранения и т. Д.) Информации в компьютерных файлах. Другими словами, в настоящее время любой компьютерный файл технологически является двоичным по своей природе. Другими словами: «любой современный файл — это только последовательность единиц и нулей ».
Таким образом, это выражение имеет смысл только для относительности двух различных понятий компьютерных файлов, потому что в информации интересна не ее природа (двоичная или другая), а ее значение, ее значение, семантика этой информации. Следовательно, это выражение вступает в игру именно в этих рамках.
Информация двоичного характера обычно сегментируется в виде слов фиксированной длины, называемых байтами . Обычно эти байты имеют длину 8 бит и поэтому называются байтами . Таким образом, двоичные компьютерные файлы представляют собой только последовательность байтов и, в более общем смысле, 8-битные байты и, следовательно, байты.
Все современные компьютерные файлы по своей технической природе являются двоичными файлами, поэтому проблема состоит в том, чтобы определить значение каждого из этих битов, этих байтов, этих байтов.
Здесь в игру вступает понятие интерпретации: для человека или для компьютера. Биты как таковые не очень выразительны для людей, которые обычно используют глифы (буквы) алфавита. Вот почему исторически, с наступлением компьютерной эры, таблицы ассоциации создавались между этими глифами (в зависимости от языка и, следовательно, страны) и байтами. Стандарт, появившийся в результате печати и, в частности, пишущих машинок, быстро появился, породив таблицу символов ASCII .
Таким образом, каждому байту соответствует данный символ ASCII. Обратите внимание, что из 256 доступных символов ASCII первые 32 не имеют связанных глифов и поэтому зарезервированы для специальных функций, производных от работы пишущих машинок того времени (таких как теперь известные « возврат каретки », « разрыв строки » или столь же известная « табуляция » и т. д.). Также обратите внимание, что последние 128 символов (то есть вторая половина таблицы) зарезервированы для специфики национальных диалектов. По историческим причинам первые 128 относятся к латинскому типу, потому что они англоязычные, и, следовательно, эта система быстро столкнулась с ее внутренними ограничениями и постепенно дополнялась (но не заменялась: она все еще существует) более современными системами, такими как, в настоящее время Юникод .
Проблема
Поскольку данные текущих компьютерных файлов хранятся в двоичной форме, первая проблема заключается в форме, которую эти данные должны принимать, чтобы быть представленными пользователю-человеку, желающему обратиться к данному файлу.
Представление данных зависит, конечно, от их природы, не физической (здесь двоичной), а от их семантической природы . Таким образом, если данные в файле (т. Е. Строки битов, байтов, байтов) являются текстовыми по своей природе, их необходимо будет представить пользователю-человеку как пишущие символы. Являются ли они графическими, в виде графики, аудиофоническими, в виде звуковых волн и т. Д.
Таким образом, проблема связана с устройством, отвечающим за представление информации, содержащейся в компьютерном файле, пользователю-человеку. Однако по умолчанию здесь неявно считается, что файлы должны быть представлены в виде печатных символов ( через таблицу соответствия ASCII).
Проблема заключается, например, в файле, содержащем аудиоинформацию, когда эта информация отображается пользователю в форме чисел (или тому подобное, но не в специальной форме звуковых волн), эта информация не будет иметь большого количества Это имеет практическое значение для человека-пользователя, потому что нам очень трудно перейти к обратной операции (то есть преобразовать умом ряд чисел, прочитанных в гармоничную симфонию).
Таким образом, первое различие, проводимое с использованием этого выражения, касается файлов, которые после преобразования в глифы имеют значение для пользователя-человека, файлов, которые, будучи преобразованными с помощью того же процесса, не имеют особого значения для пользователя-человека.
Двоичный файл представляет собой один содержащий данные в виде байт , которые , следовательно , имеют смысл только для программного обеспечения , которое использует их (и не для конечных пользователей). Если по строгому определению какой-либо файл является двоичным, использование требует, чтобы файл квалифицировался как двоичный, чтобы указать, что это не текстовый файл. Эти файлы можно открывать с помощью текстовых редакторов (не рекомендуется для неопытных пользователей), но данные будут плохо представлены и, прежде всего, непонятны.
(Большинство существующих файлов представляют собой двоичные файлы, в их число входят файлы, содержащие звук , видео , изображения , машинный язык , отпечатки памяти и т. Д.).
Чтобы описать организацию данных в этом файле, он называется форматом файла .
Семантическая эволюция
В начале 1980-х форматы двоичных файлов были систематизированы в средах микрокомпьютеров, где пространство памяти было критически важным. Действительно, двоичный формат часто представляет собой текстовый файл более компактного формата (он занимает меньше места в памяти и на периферийных устройствах хранения ). Объем памяти сам по себе недостаточен, чтобы объяснить это распространение.
Собственные файлы
Бинарный формат файла может быть бесплатным (например, формат файла Gimp XCF ). Если это не так, необходимо применить к нему методы обратной инженерии , что замедляет понимание. Благодаря сохраняемому в секрете двоичному файловому формату ( закрытому формату ) издатель проприетарного программного обеспечения может контролировать своих клиентов, ограничивая возможность взаимодействия своих файлов, поскольку его конкуренты вряд ли смогут создать эквивалентное программное обеспечение, которое будет использовать его двоичный формат файла как а также собственное ПО.
Однако в таких операционных системах, как Unix , культура была больше ориентирована на форматы простого текста. Это остается верным: файлы конфигурации, в частности, почти всегда доступны для чтения любым текстовым редактором .
Наиболее распространенными двоичными файлами являются файлы изображений, проприетарные форматы офисного программного обеспечения ( текстовые процессоры , электронные таблицы и т. Д.) И скомпилированные приложения .
Двоичные файлы и программы
На 8-битных машинах двоичный файл часто представляет собой скомпилированную программу, чаще всего написанную на ассемблере для экономии места. В заголовке файла указан адрес начала ячейки памяти, а также адрес выполнения.
Визуализация
Для правильного просмотра содержимого двоичных файлов предпочтительно использовать шестнадцатеричный редактор. Эти редакторы могут преобразовывать каждый байт в шестнадцатеричные числа и символы ASCII. Использование так называемых «текстовых» редакторов (с использованием 256 символов ASCII компьютера — в зависимости от страны и используемого шрифта) не рекомендуется, поскольку они не подходят. Действительно, они будут медленными, иногда смогут открывать файлы ограниченного размера и будут интерпретировать первые 32 байта как символы ASCII (которые являются специальными и действуют на сам текст). Например, байт 13 будет интерпретирован редактором как табуляция, байт 0, вероятно, не будет отображаться или заблокирует отображение остальной части файла .
Если визуализация возможна с помощью шестнадцатеричных редакторов, следует избегать подобного изменения двоичных файлов, поскольку они могут серьезно повлиять на работу программного обеспечения, которое их использует (или самого программного обеспечения, когда речь идет о так называемых «исполняемых» файлах). В большинстве случаев файл будет распознаваться программным обеспечением как поврежденный из-за методов безопасности (таких как биты четности, расположенные в конце логических блоков), реализуемых используемым форматом.
Примечания и ссылки
(fr) Эта статья частично или полностью взята из английской статьи в Википедии под названием « Двоичный файл » ( см. список авторов ) .
Смотрите также
Статьи по Теме
Внешние ссылки
- (ru) BEYE — это проект Binary EYE
В чем отличие бинарного файла от исходного?
Во время работы с Linux у вас есть возможность на выбор использовать два совсем разных способа установки программ, а именно:
Выбрать нужный необходимо отталкиваясь от ваших потребностей и требований к системе, ну и конечно от наличия навыков и опыта в развертывании ПО. Рассмотрим отдельно каждый из методов, их плюсы, а также минусы и трудности, которые могут встретиться при установке.
Бинарный файл
Бинарный файл — это фактическая программа, которая уже полностью готовая к использованию. Это исполняемый файл, который создается при компиляции из исходного кода. Как правило, они имеют все необходимые библиотеки, встроенные в них, или устанавливают / разворачивают их по мере необходимости (в зависимости от того, как было написано ПО). В большинстве случаев предоставляются в архивном формате.
Для установки требуется специальная программа для распаковки этих файлов и помещения их на компьютер. То есть менеджер пакетов вашего дистрибутива Linux (например, apt, yum и т. д.). Менеджер пакетов также выполняет и другие полезные функции кроме распаковки, такие как отслеживание установленных файлов и управление обновлениями программного обеспечения.
Преимущества и плюсы использования бинарных файлов
- Файл сразу готов к запуску. Если у вас есть бинарный файл, разработанный для вашего процессора и операционной системы, скорее всего, вы сможете запустить программу, и все будет работать как надо уже с первого раза.
- Выполнение меньшего количества конфигураций. Вам не нужно настраивать целую кучу параметров конфигурации, чтобы использовать программу, файл просто будет использовать общую конфигурацию по умолчанию.
- Если что-то пойдет не так, и случится ошибка, будет проще найти помощь в Интернете, поскольку бинарный файл предварительно скомпилирован, и логично, что другие люди могут его уже использовали, а это значит, что вы используете аналогичную программу, как и у других пользователей, а не уникальную, оптимизированную для вашей системы, поэтому можно будет найти советы о том как решить полученные ошибки или получить информацию, что следует делать дальше.
Недостатки и минусы использования
- Вы не можете видеть (иметь доступ) и редактировать исходный код, поэтому вы не имеете возможности получить оптимизацию программы под вашу систему, ваши потребности и предпочтения.
Исходные файлы
Исходные файлы — файлы для “сборки” утилиты/ПО в бинарный файл. Исходный код программного обеспечения для Linux поставляется в виде сжатых tar-файлов, которые обычно имеют расширения .tar.gz или .tar.bz2. Инструменты используются для упаковки исходного кода в tarballs, где «tar» (используется для объединения нескольких файлов в один), «gzip» или bzip2 (используется для сжатия).
Чтобы получить tar-архив с исходным кодом для определенного программного обеспечения, вам нужно знать URL-адрес к tar-архиву. После чего нужно распаковать скачанный tar-архив специальной командой tar для определенного типа расширения архива, чтобы получить доступ к файлам и возможность работать с исходником. Следующим шагом выполняются нужные настройки среды для компиляции и установки программного обеспечения из исходного кода.
Исходные файлы, написанные на разных языках, и нуждаются в специальных компиляторах и командах для преобразования его в исполняемый бинарный файл, который будет читаемым для системы и затем сможет запустить ваш компьютер.
Специальный набор инструментов помогает автоматизировать этот процесс. На десктопах Linux это обычно происходит в форме программы командной строки под названием make. Выше перечислены стандартные этапы, при выполнении каких возможно могут появляться ошибки, и будет необходимо выполнять дополнительные манипуляции, в этом и есть сложность внедрения проектов через исходные файлы.
Касательно вопроса, где можно найти исходный код к продукту, вариантов много, в большинстве случаев Вы можете загрузить исходный код проекта с таких сервисов, как GitHub или BitBucket. Некоторые владельцы ПО могут даже разместить его на личном веб-сайте.
Также шаг который лучше не упускать — это ознакомление с документацией к проекту, там могут содержаться важные данные о всех возможностях, последних обновлениях, детали и подсказки по компиляции и установке этого ПО.
Преимущества и плюсы использования исходных файлов
- Дает гибкость в конфигурации программного обеспечения под себя, нужды и требования конкретной системы.
- Хороший вариант для приобретения практических навыков и получения информации о работе и понимания приложения в системе в целом.
Недостатки и минусы использования
- При возникновении ошибки сложно отыскать ее решение, тем самым простой процесс с развертыванием пакетов может превратится в многочасовое занятие.
- К началу установки ПО нужно выполнять дополнительные действия, настройки и установки. Например, Вы должны иметь установленный компилятор, необходимо вручную установить все необходимые библиотеки, которые также часто должны быть скомпилированы.
К минусам этот пункт можно и не относить, но для установки ПО с исходника потребуется уже наличие теоретических знаний и необходимых навыков в понимании документации к продукту, работы с терминалом и т.д., тут обычному пользователю может быть сложно.
Оба метода хороши и несут в себе разные цели использования. В большинстве случаев достаточно выбрать стандартный метод с помощью бинарных файлов.
3.12 Бинарные форматы
Для понимания почему FreeBSD использует формат elf (5) , вам потребуется сначала немного узнать о трех «доминирующих» исполняемых форматах для UNIX ®:
Старейший и «классический» объектный формат UNIX . Он использует короткий и компактный заголовок с магическим числом в начале, которое часто используется для описания формата (смотрите a.out (5) с более подробной информацией). Он содержит три загружаемых сегмента: .text, .data и .bss плюс таблицу символов и таблицу строк.
Объектный формат SVR3. Заголовок включает таблицу разделов, так что могут быть сегменты кроме .text, .data и .bss.
Наследник формата COFF , поддерживающий множественные сегменты и 32-битные или 64-битные значения. Одно важное замечание: ELF был разработан в предположении что есть только по одному ABI на одну архитектуру. Это предположение совершенно не верно, и не только в мире коммерческих SYSV (в котором есть как минимум три ABI: SVR4, Solaris, SCO).
FreeBSD пытается обойти эту проблему, в частности предоставляя утилиту для оглавления известного исполняемого файла ELF информацией об ABI с которым он совместим. Обратитесь к странице справочника brandelf (1) за более подробной информацией.
FreeBSD имеет произошла из «классического» лагеря и использовала формат a.out (5) , технологию опробованную и проверенную на многих поколениях релизов BSD, до начала ветки 3.X. Хотя собирать и запускать родные бинарные файлы ELF (и ядро) в системе FreeBSD можно было несколько раньше, FreeBSD вначале сопротивлялась «проталкиванию» ELF как формата по умолчанию. Почему? Когда лагерь Linux производил болезненный переход к ELF , у него не было большого преимущества перед исполняемым форматом a.out , из-за негибкого, основанного на таблице переходов механизма разделяемых библиотек, что делало создание разделяемых библиотек очень трудным для поставщиков и разработчиков. Когда доступные инструменты ELF предоставили решение проблемы разделяемых библиотек, и появилась некоторая перспектива, цена перехода была признана допустимой и он был сделан. Механизм разделяемых библиотек FreeBSD близок по стилю к механизму разделяемых библиотек SunOS ™ от Sun, и поэтому очень прост в использовании.
Итак, почему так много разных форматов?
Давно, в темном далеком прошлом, оборудование было простым. Это простое оборудование поддерживало простые, маленькие системы. a.out был совершенно адекватен задаче представления бинарных файлов на таких простых системах (PDP-11). Люди, портировавшие UNIX с этих простых систем, оставили a.out формат потому, что он был достаточен для ранних портов UNIX на архитектуры подобные Motorola 68k, VAXen, etc.
Затем какой-то смышленый инженер по оборудованию решил что если он сможет заставить программы исполнять некоторые трюки, то сможет несколько упростить дизайн и заставить ядро CPU работать быстрее. Хотя это было сделано с новым типом оборудования (известного сейчас как RISC ), формат a.out не подходил для него, и было разработано множество форматов чтобы получить лучшую производительность на таком оборудовании по сравнению с той, которую мог предоставить простой формат a.out . Были изобретены форматы COFF , ECOFF и некоторые другие малоизвестные форматы, и их ограничения были учтены когда все похоже остановились на ELF .
Кроме того, размеры программ стали огромны, а диски (и оперативная память) остались относительно малы, поэтому появилась концепция разделяемых библиотек. Система VM также стала более сложной. Хотя все эти усовершенствования были выполнены с форматом a.out , его полезность все больше и больше уменьшалась с каждым нововведением. К тому же потребовалась динамическая загрузка во время выполнения, или выгрузка частей программы после выполнения стартового кода для экономии памяти или места на диске. Языки усложнялись и потребовался автоматический вызов кода перед главной программой. Множество изменений было внесено в формат a.out чтобы все это появилось и в основном работало некоторое время. Настал момент, когда a.out не смог решить все эти проблемы без чрезмерного увеличения размера и сложности. В то время как ELF решил многие из этих проблем, перевод этого формата с системы на систему болезненен. Поэтому формату ELF пришлось подождать пока не стало более болезненным оставаться с a.out чем перейти на ELF .
Тем временем, инструменты разработки, от которых произошли инструменты разработки FreeBSD (особенно ассемблер и загрузчик) развивались в двух параллельных направлениях. Направление FreeBSD добавило разделяемые библиотеки и устранило некоторые ошибки. Люди из GNU, написавшие эти программы, переписали их и добавили простую поддержку сборки кросскомпиляторов, подключения различных форматов в будущем и так далее. Многим требовалось собрать кросскомпиляторы для FreeBSD, и это не удалось, поскольку устаревшие исходные тексты FreeBSD для as и ld не подходили для этой задачи. Новый набор инструментов GNU ( binutils ) поддерживает кросскомпилирование, ELF , разделяемые библиотеки, C++, расширения и т.д. В дополнение, многие поставщики выпустили программы в формате ELF и они хорошо подходят для запуска в FreeBSD.
ELF более выразителен чем a.out позволяет базовой системе быть более гибкой. ELF лучше поддерживается, и предоставляет поддержку кросскомпиляторов, что важно для многих людей. ELF может быть немного медленнее чем a.out , но замерить это сложно. Есть также множество деталей, отличающихся для этих двух форматов, в том как они отображают страницы, обрабатывают начальный код, и т.д. В этом нет ничего очень важного, но они различаются. В настоящее время поддержка a.out убрана из ядра GENERIC , и со временем будет убрана из ядра как только потребность в запуске старых программ a.out останется в прошлом.
Prev Home Next Устройства и файлы устройств Up Дополнительная информация Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ .
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в < questions@FreeBSD.org >.
По вопросам связанным с этой документацией, пишите < doc@FreeBSD.org >.
По вопросам связанным с русским переводом документации, пишите < frdp@FreeBSD.org.ua >.Разбор бинарных форматов. Часть 1
Одна из самых сложных и интересных задач, с которыми сталкивается реверс инженер — это анализ бинарных файлов. Зачастую это может быть просто уже известный формат, и интерес с точки зрения анализа здесь появляется в тот момент, когда нужно написать свой просмотрщик и/или сделать более наглядной структуру файла. В данной статье попробуем проанализировать несколько бинарных файлов.
Основные понятия для начинающих
Любой кусочек информации в компьютере записан в двоичном формате, поэтому для того чтобы сохранить что-то полезное, нужно информацию преобразовать в этот самый вид. Для понимания что именно скрывается в бинарных файлах критически важно:
- не бояться читать большое количество цифр.
- понимать зачем и как структурированы цифры внутри файла.
Основной единицей представления данных, которые обычно используют для того чтобы хотя бы приблизительно продемонстрировать информацию в «сыром» виде, являются байты. Выглядеть это может вот так:
Просто так прочитать такую информацию практически невозможно, однако, были придуманы специальные правила, какие именно данные должны находиться на какой позиции в файле. То есть это все еще просто нули и единицы, просто их скомпоновали так, чтобы было проще читать.
Что за правила используют для описания файла? Это спецификации форматов файлов, их можно найти в сети, обычно формат файла разрабатывается для ОС, либо для конкретного программного обеспечения. В обоих случаях ресурсы разработчиков софта должны содержать спецификацию. Попробуем найти спецификацию для формата файлов PE, которые используются для работы приложений в ОС Windows. Вот здесь лежит эта самая спецификация. Обычно это очень массивное писание, где по каждому параметру есть хотя бы общие замечания. Что можно или нужно сохранять, но эти правила не носят обязательный характер, так как сам разработчик программного обеспечения может отдельные параметры в файлах использовать под свои задачи. Поэтому в сети очень часто можно найти исследования обычных форматов файлов, но там будет описываться какая‑то особенность, которую не записали в спецификации.
Стоит так же отметить, что даже сами разработчики для более простого восприятия бинарного формата файла могут представлять его в виде таблицы. Это только общее представление которое позволяет добавить визуальную составляющую или некую абстракцию, чтобы проще было создавать парсеры для разбора таких файлов. Кстати вот здесь можно найти у самих MS схематичное представление PE файла когда он хранится на диске и когда попадает в оперативную память.
Давайте попробуем рассмотреть инструменты для быстрого просмотра файлов, которые есть в наличии.
Инструменты для просмотра структуры и данных
Универсальным способом просмотра бинарных файлов является открытие файлов с помощью шестнадцатеричного рекдатора. Одними из наиболее популярных в этой области являются:
- 010 Hex Editor
- Hiew
- WinHex Editor
Этими инструментами можно пользоваться в двух случаях. Первый — если для написания своего разборщика нужно понять что именно записано в файле. Второй случай — у некоторых приложений есть функции разметки файла. Попробуем как раз задействовать второй вариант.
Для теста возьмем вот этот файл. Откроем его в Hiew:
Это приложение позволяет смотреть сырые данные, но так же содержит дизассемблер, поэтому если мы будем смотреть бинарный файл, в котором есть команды для процессора, то возможно их увидеть. Для этого достаточно нажать кнопку Enter.
В общем‑то процедура рассмотрения файла закончена, но это далеко не все возможности. Hiew так же поддерживает плагины, поэтому можно проводить дополнение функционала. Плагинов на самом деле существует очень много, но для нашей статьи наиболее интересен вот этот. Это плагин, который собрали на основе фреймворка для разбора форматов файлов и сетевых протоколов KaiTai Struct. Что же умеет этот плагин? Посмотрим на файл через него. Делать дополнительных настроек не нужно, достаточно просто скопировать файл hem из репозитория в директорию с hiew и открыть файл. Чтобы убедиться, что все работает как нужно, нажмите кнопку F11. Должен появиться список плагинов, который показан на картинке ниже:
А теперь просто выбираем плагин и смотрим, что он показывает. Как видно, у плагина есть целый список заготовленных форматов файлов, которые можно изучать с точки зрения структуры файла. Работает это так — KaiTai позволяет написать формат файла, так как это видит разработчик, а затем он самостоятельно подсвечивает отдельные части, которые могут быть подписаны или преобразованы для чтения. Выглядеть это может вот так для исполняемого файла ELF:
Теперь при наведении на определенную зону файла будет показываться её название. Это удобно, когда нужно понять какая часть файлика сейчас может быть считана приложением или просто для того чтобы понимать что записано в файл.
Попробуем на других форматах:
Кстати, нечто подобное можно делать и для Hex 010, но там для описания формата файла можно пользоваться так называемыми шаблонами, они пишутся с помощью языка программирования C. Можно сказать, это просто заголовочный файл, который определяет структуру файла, а Hex 010 заполняет его данными. Выглядит это так:
Таким образом можно наметить структуру для будущего приложения, которое сможет просматривать отдельные характеристики файла или пытаться его прочитать и отобразить. В следующей статье попробуем разобраться с сетевыми протоколами и методами их разбора.
А сейчас приглашаю вас на бесплатный урок, в рамках которого рассмотрим способы, с помощью которых, можно перехватить API функции.
- реверс-инжиниринг
- reverse-engineering
- бинарные форматы