СПОСОБ СОЗДАНИЯ И ИСПОЛЬЗОВАНИЯ ФОРМАТА ИСПОЛНЯЕМОГО ФАЙЛА С ДИНАМИЧЕСКИМ РАСШИРЯЕМЫМ ЗАГОЛОВКОМ Российский патент 2020 года по МПК G06F9/00 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Из уровня техники известно решение (US8549647B1, US AIR FORCE, опубл. 01.10.2013), которое описывает способ классификации переносимого исполняемого файла. Недостатком данного решения является то, что классификация не является собственно решением для встраивания новых спецификаций, их интерпретации и обработки.

Известны также решения, описывающие форматы исполняемых файлов. Такие решения, например, раскрыты в следующих документах: US10127381В2, EP1560112A1, EP1749266A2.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Данное техническое решение направлено на устранение недостатков, присущих существующим решениям из известного уровня техники.

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

Главными отличиями заявленного решения от известных из уровня техники является то, что:

- в заявленном решении заголовок исполняемого файла описан на абстрактном синтаксисе с применением правила кодирования.

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

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

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

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

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

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

Кроме того, данная возможность будет достигнута путем использования ряда предлагаемых в заявленном решении подходов:

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

- предоставления возможности расширения для следующих версий формата;

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

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

Техническим результатом является создание нового формата исполняемого файла компьютерных программ, обладающий компактностью и гибкой расширяемостью благодаря использованию при формировании заголовка файла языка описания абстрактного синтаксиса данных (ASN.1) совместно с правилом уплотненного кодирования (PER), который не зависит от архитектуры используемого компьютера.

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

Дополнительным техническим результатом, проявляющимся при решении данной технической задачи, является:

- защита исполняемых файлов на предмет вставки вредоносного ПО и скриптов путем спецификации параметров файла (контрольная сумма, размер и др.) в кодированном заголовке файла.

Поскольку использование правил уплотнённого кодирования (PER), приводит еще к одному дополнительному эффекту, в отличии от других известных правил (BER, DER, CER) и структурного подхода описания заголовка, это предоставляет еще один уровень защищённости от вредоносных программ.

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

- встраивание любых сертификатов и протоколов в заголовок файла;

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

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

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

- во время сборки исполняемого файла выполняют следующие шаги:

- обрабатывают файлы с исходным кодом, объектные файлы и библиотеки, в результате данной обработки формируют секции кода и секции данных;

- формируют заголовок исполняемого файла применяя язык описания абстрактного синтаксиса данных (ASN.1);

- кодируют в заголовке исполняемого файла информацию о секциях кода и секциях данных в заголовке;

- создают отдельную секцию таблицы интерфейсов для компонентов;

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

- на выходе формируют исполняемый файл в виде машинного или байт кода, или их комбинации с динамическим расширяемым заголовком, закодированным согласно правилу уплотненного кодирования (PER);

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

ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 иллюстрирует заявленный компьютерно-реализуемый способ;

Фиг. 2 иллюстрирует пример заголовка на ASN.1;

Фиг. 3 иллюстрирует пример заголовка формата исполняемого файла;

Фиг. 4 иллюстрирует блок-схему процесса формирования исполняемого файла;

Фиг. 5 иллюстрирует блок-схему процесса подготовки к запуску исполняемого файла.

ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

Наиболее известными и популярными форматами исполняемых файлов являются, такие как:

ELF (*nix формат) :

#define EI_NIDENT 16

typedef struct {

unsigned char e_ident[EI_NIDENT];

Elf32_Half e_type;

Elf32_Half e_machine;

Elf32_Word e_version;

Elf32_Addr e_entry;

Elf32_Off e_phoff;

Elf32_Off e_shoff;

Elf32_Word e_flags;

Elf32_Half e_ehsize;

Elf32_Half e_phentsize;

Elf32_Half e_phnum;

Elf32_Half e_shentsize;

Elf32_Half e_shnum;

Elf32_Half e_shstrndx;

} Elf32_Ehdr;

typedef struct {

unsigned char e_ident[EI_NIDENT];

Elf64_Half e_type;

Elf64_Half e_machine;

Elf64_Word e_version;

Elf64_Addr e_entry;

Elf64_Off e_phoff;

Elf64_Off e_shoff;

Elf64_Word e_flags;

Elf64_Half e_ehsize;

Elf64_Half e_phentsize;

Elf64_Half e_phnum;

Elf64_Half e_shentsize;

Elf64_Half e_shnum;

Elf64_Half e_shstrndx;

} Elf64_Ehdr;

Mach-o (Mac OS X формат) :

struct mach_header {
unsigned long  magic;      /* Mach magic number identifier */
cpu_type_t     cputype;    /* cpu specifier */
cpu_subtype_t  cpusubtype; /* machine specifier */
unsigned long  filetype;   /* type of file */
unsigned long  ncmds;      /* number of load commands */
unsigned long  sizeofcmds; /* size of all load commands */
unsigned long  flags;      /* flags */

};

MZ, PE (Windows форматы) :

typedef struct _IMAGE_DOS_HEADER {

WORD e_magic; /* 00: MZ Header signature */

WORD e_cblp; /* 02: Bytes on last page of file */

WORD e_cp; /* 04: Pages in file */

WORD e_crlc; /* 06: Relocations */

WORD e_cparhdr; /* 08: Size of header in paragraphs */

WORD e_minalloc; /* 0a: Minimum extra paragraphs needed */

WORD e_maxalloc; /* 0c: Maximum extra paragraphs needed */

WORD e_ss; /* 0e: Initial (relative) SS value */

WORD e_sp; /* 10: Initial SP value */

WORD e_csum; /* 12: Checksum */

WORD e_ip; /* 14: Initial IP value */

WORD e_cs; /* 16: Initial (relative) CS value */

WORD e_lfarlc; /* 18: File address of relocation table */

WORD e_ovno; /* 1a: Overlay number */

WORD e_res[4]; /* 1c: Reserved words */

WORD e_oemid; /* 24: OEM identifier (for e_oeminfo) */

WORD e_oeminfo; /* 26: OEM information; e_oemid specific */

WORD e_res2[10]; /* 28: Reserved words */

DWORD e_lfanew; /* 3c: Offset to extended header */

} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

#define IMAGE_DOS_SIGNATURE 0x5A4D /* MZ */

#define IMAGE_OS2_SIGNATURE 0x454E /* NE */

#define IMAGE_OS2_SIGNATURE_LE 0x454C /* LE */

#define IMAGE_OS2_SIGNATURE_LX 0x584C /* LX */

#define IMAGE_VXD_SIGNATURE 0x454C /* LE */

#define IMAGE_NT_SIGNATURE 0x00004550 /* PE00 */

и имеют структурное описание заголовков, которые, в свою очередь, зависят от размера полей (16-бит, 32-бита, 64-бита), их выравнивания и порядка следования байтов (big-endian и little-endian).

В отличии от известных из уровня техники форматов исполняемых файлов, предлагаемое техническое решение, выполняет другой способ формирования заголовка формата исполняемого файла, а именно использование языка описания абстрактного синтаксиса данных (ASN.1), который не зависит от архитектуры машины, разрядности и порядка следования байтов. Для кодирования заголовка ASN.1 формата исполняемого файла, используется правила уплотненного кодирования (PER).

Ниже приведен пример заголовка на ASN.1 для сравнения с приведёнными выше структурными описаниями заголовков:

--

-- Abstract Syntax Notion (ASN.1) file for Executable File Format (EFF) Version 1

--

ECO-EFF DEFINITIONS AUTOMATIC TAGS ::=

BEGIN

Header-EFF ::= SEQUENCE

{

version INTEGER,

standardHeader StandardHeader-EFF,

nonStandardHeader NonStandardHeader-EFF OPTIONAL,

...

}

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

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

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

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

На Фиг. 1 представлен компьютерно-реализуемый способ (100) создания и использования формата исполняемого файла с динамическим расширяемым заголовком, выполняемый с помощью вычислительного устройства.

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

На этапе (101) обрабатывают файлы с исходным кодом, объектные файлы и библиотеки, в результате данной обработки формируют секции кода и секции данных.

На этапе (102) формируют заголовок исполняемого файла применяя язык описания абстрактного синтаксиса данных (ASN.1) и на этапе (103) кодируют в заголовке исполняемого файла информацию о секциях кода и секциях данных в заголовке.

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

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

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

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

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

Другой такой задачей может быть, включение специализированной, т.е. для узкого круга задач, спецификации для работы с портами ввода/вывода для микроконтроллеров. Тот факт, что адреса и количество портов у одного семейства микроконтроллеров различны, а объем памяти ограничен, заставляют разработчиков с помощью механизмов условной компиляции для одного семейства микроконтроллеров собирать несколько версий исполняемого кода, отличающихся только адресами портов ввода/вывода. Если же логику выбора адреса портов в зависимости от серии микроконтроллера вставлять непосредственно в исполняемый код, то код разрастается (могут быть проблемы с объемом памяти), плюс добавляется процессорное время на проверку серии микроконтроллера и выбора соответствующего адреса порта ввода/вывода.

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

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

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

Далее на выходе формируют исполняемый файл в виде машинного или байт кода, или их комбинации с динамическим расширяемым заголовком, закодированным согласно правилу уплотненного кодирования (PER) (на этапе (106)).

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

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

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

Формат исполняемого файла для компонентной ОС должен содержать и предоставлять необходимые данные для успешной подготовки и запуску программы.

Архитектура компонентной ОС может быть выполнена с возможностью одновременной работы микроядер разных поколений (например, ОС созданные по Адаптированной Объектной Модели Компонентов (АОМК) архитектуре), которая напрямую связана с развитием аппаратной части, что в свою очередь требует от формата исполняемого файла обратной совместимости и независимость от архитектуры машины. Также компонентная ОС предоставляет разработчикам возможность создавать специализированные решения в зависимости от требований, что в свою очередь так же требует от формата исполняемого файла помимо стандартных средств предоставления сведений обработки данных файла, включать в него нестандартные данные, определяемые самим разработчиком исходя из требований для специализированных решений.

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

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

Одним из основных отличий нового формата исполняемого файла является наличие секции интерфейсов, содержащей таблицу интерфейсов, которая является альтернативой таблицам импорта и экспорта, но не ограничивает использование последних. Наличие данной таблицы обусловлено архитектурой компонентной ОС, в которой взаимодействие построено на использовании интерфейсов по Адаптированной Объектной Модели Компонентов (АОМК) технологии.

На фиг.3 представлен пример заголовка формата исполняемого файла.

На фиг.4 представлен процесс формирования формата исполняемого файла. При обработке объектных файлов и библиотек формируются секции кода и секции данных, информация о которых кодируется в заголовке формата исполняемого файла. В случаях определения экспортируемых указателей на фабрики компонентов, создается секция таблицы интерфейсов, в которой для каждого компонента прописывается UGUID компонента и указатель на интерфейс фабрики компонентов соответствующего компонента (адрес –смещение в коде относительно базового адреса). Также дополнительно могут формироваться секции поправок, секции, содержащие отладочную информацию и т.п., информация о которых кодируется в заголовке.

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

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

На фиг.5 представлен процесс подготовки и запуска исполняемого файла.

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

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

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

Изобретение относится к области вычислительной техники. Техническим результатом является создание нового формата исполняемого файла компьютерных программ, обладающего компактностью и гибкой расширяемостью. Компьютерно-реализуемый способ включает создание и использование формата исполняемого файла с динамическим расширяемым заголовком, выполняется с помощью вычислительного устройства, причем во время сборки исполняемого файла обрабатывают файлы с исходным кодом, объектные файлы и библиотеки, в результате чего формируют секции кода и секции данных; формируют заголовок исполняемого файла, применяя язык описания абстрактного синтаксиса данных (ASN.1); кодируют в заголовке исполняемого файла информацию о секциях кода и секциях данных в заголовке; создают отдельную секцию таблицы интерфейсов для компонентов; формируют специализированные секции, с определенной самим пользователем или разработчиком приложений спецификацией, и запускают делегирующий процесс формирования данных секций, информация по данным секциям кодируется в заголовке, включающем в себя такую опциональную нестандартную спецификацию; на выходе формируют исполняемый файл в виде машинного или байт кода или их комбинации с динамическим расширяемым заголовком, закодированным согласно правилу уплотненного кодирования (PER); в процессе исполнения файла операционная система считывает заголовок файла и определяет имеющиеся секции, включая ссылки на внешние компоненты и их интерфейсы, секции с машинным либо байт кодом, включая секции, определенные пользователем, и ссылки на процессы делегаты для обработки данных пользовательских секций. 5 ил.

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

обрабатывают файлы с исходным кодом, объектные файлы и библиотеки, в результате данной обработки формируют секции кода и секции данных;

формируют заголовок исполняемого файла, применяя язык описания абстрактного синтаксиса данных (ASN.1);

кодируют в заголовке исполняемого файла информацию о секциях кода и секциях данных в заголовке;

создают отдельную секцию таблицы интерфейсов для компонентов;

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

на выходе формируют исполняемый файл в виде машинного или байт кода или их комбинации с динамическим расширяемым заголовком, закодированным согласно правилу уплотненного кодирования (PER);

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