Файл com что это

Обновлено: 24.01.2025

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

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

Наиболее технически интересная часть заключается в том, что для создания игры не понадобились никакие инструменты разработки DOS! Я использовал только обычный компилятор Linux C (gcc). В реальности даже нельзя собрать DOS Defender под DOS. Я рассматриваю DOS только как встроенную платформу, что и есть единственная форма, в которой DOS всё ещё существует сегодня. Вместе с DOSBox и DOSEMU это довольно удобный набор инструментов.

Если вас интересует только практическая часть разработки, перейдите к разделу «Обманываем GCC», где мы напишем DOS COM программу “Hello, World” с GCC Linux.

Когда я начал этот проект, то не думал о GCC. В реальности я пошёл по этому пути, когда обнаружил пакет bcc (Bruce’s C Compiler) для Debian, который собирает 16-битные бинарники для 8086. Его держат для компиляции загрузчиков x86 и прочего, но bcc также можно использовать для компиляции DOS COM файлов. Это меня заинтересовало.

Для справки: 16-битный микропроцессор Intel 8086 вышел в 1978 году. У него не было никаких причудливых функций современных процессоров: ни защиты памяти, ни инструкций с плавающей запятой и только 1 МБ адресуемой RAM. Все современные десктопы и ноутбуки x86 всё ещё могут притвориться этим 16-битным процессором 8086 сорокалетней давности, с такой же ограниченной адресацией и всё такое. Это нехилая обратная совместимость. Такая функция называется реальным режимом. Это режим, в котором загружаются все компьютеры x86. Современные ОС сразу переключаются в защищённый режим с виртуальной адресацией и безопасной многозадачностью. DOS так не поступал.

К сожалению, bcc — не компилятор ANSI C. Он поддерживает подмножество K&R C, а также встроенный ассемблерный код x86. В отличие от других компиляторов 8086 C, у него нет понятия «дальних» или «длинных» указателей, поэтому для доступа к другим сегментам памяти (VGA, тактовые импульсы и т. д.) необходим встроенный ассемблерный код. Примечание: остатки этих «длинных указателей» 8086 до сих сохранились в Win32 API: LPSTR , LPWORD , LPDWORD и др. Тот встроенный ассемблер даже близко не сравнится со встроенным ассемблером GCC. На ассемблере нужно вручную загружать переменные из стека, а поскольку bcc поддерживает два разных соглашения о вызовах, то переменные в коде следует жёстко закодировать в соответствии с одним или другим соглашением.

Учитывая такие ограничения, я решил искать альтернативы.

DJGPP — порт GCC под DOS. Реально очень впечатляющий проект, который переносит под DOS почти весь POSIX. Многие портированные под DOS программы сделаны на DJGPP. Но он создаёт только 32-битные программы для защищённого режима. Если в защищённом режиме нужно работать с аппаратным обеспечением (например, VGA), то программа делает запросы к сервису интерфейса защищённого режима DOS (DPMI). Если бы я взял DJGPP, то не смог бы ограничиться единственным автономным бинарником, потому что пришлось бы поиметь и сервер DPMI. Производительность тоже страдает от запросов к DPMI.

Получить необходимые инструментальные средства для DJGPP сложно, мягко говоря. К счастью, я нашел полезный проект build-djgpp, который всё запускает, по крайней мере, на Linux.

Либо там серьёзная ошибка, либо официальные бинарники DJGPP опять заразились вирусом, но при при запуске моих программ в DOSBox постоянно возникала ошибка “Not COFF: check for viruses”. Для дополнительной проверки, что вирусы не на моей собственной машине, я настроил среду для DJGPP на своём Raspberry Pi, который действует как чистая комната. Это устройство на базе ARM невозможно заразить вирусом x86. И всё равно возникала та же проблема, и все двоичные хэши совпадали между машинами, так что это не моя вина.

Так что учитывая это и проблему DPMI, я начал искать дальше.

На чём я в итоге остановился — так это на хитром трюке по «обману» GCC для сборки DOS COM-файлов реального режима. Трюк работает до 80386 (что обычно и нужно). Процессор 80386 выпущен в 1985 году и стал первым 32-битным x86 микропроцессором. GCC по-прежнему придерживается этого набора инструкций, даже в среде x86-64. К сожалению, GCC никак не может производить 16-битный код, так что от изначальной цели сделать игру для 8086 пришлось отказаться. Впрочем, это не имеет значения, потому что целевая платформа DOSBox по сути является эмулятором 80386.

В теории трюк должен работать и в компиляторе MinGW, но там есть давняя ошибка, которая мешает ему работать правильно (“cannot perform PE operations on non PE output file”). Впрочем, её можно обойти, и я делал это сам: следует удалить директиву OUTPUT_FORMAT и добавить дополнительный шаг objcopy ( objcopy -O binary ).

Hello World в DOS

Для демонстрации создадим досовскую COM-программу “Hello, World” с помощью GCC на Linux.

В этом способе есть главное и значительное препятствие: стандартной библиотеки не будет. Это как писать операционную систему с нуля, за исключением нескольких служб, которые обеспечивает DOS. Это значит, нет printf() и тому подобного. Вместо этого мы попросим DOS вывести строку в консоль. Создать запрос к DOS требует запуска прерывания, что означает встроенный ассемблерный код!

В DOS девять прерываний: 0x20, 0x21, 0x22, 0x23, 0x24, 0х25, 0x26, 0x27, 0x2F. Самое главное, которое нас интересует, это 0x21, функция 0x09 (вывести строку). Между DOS и BIOS есть тысячи функций, названных по такому шаблону. Я не собираюсь пытаться объяснить ассемблер x86, но вкратце номер функции забивается в регистр ah — и прерывание 0x21 срабатывает. Функция 0x09 также принимает аргумент — указатель на строку для печати, который передается в регистрах dx и ds .

Вот функция print() встроенного ассемблера GCC. Строки, передаваемые этой функции, должны заканчиваться символом $. Почему? Потому что DOS.

Код объявлен volatile , поскольку у него побочный эффект (печать строки). Для GCC ассемблерный код непрозрачен, и оптимизатор полагается на ограничения выхода/входа/клоббера (последние три строки). Для таких DOS-программ любой встроенный ассемблер будет с побочными эффектами. Это потому что он пишется не для оптимизации, а для доступа к аппаратным ресурсам и DOS — вещей, недоступных простому C.

Нужно также позаботиться о вызывающем операторе, потому что GCC не знает, что память, на которую указывает string , когда-либо читалась. Вероятно, массив, который поддерживает строку, тоже придётся объявить volatile . Всё это предвещает неизбежное: любые действия в такой среде превращаются в бесконечную борьбу с оптимизатором. Не все из этих битв можно выиграть.

Теперь к основной функции. Её название по идее не важно, но я избегаю называть её main() , потому что у MinGW есть забавные идеи, как обрабатывать конкретно такие символы, даже если его просят не делать этого.

COM-файлы ограничены размером 65279 байт. Это связано с тем, что сегмент памяти x86 составляет 64 КБ, а DOS просто загружает COM-файлы в адрес 0x0100 сегмента и выполняет. Заголовков нет, только чистый бинарник. Поскольку программа COM в принципе не может иметь значительный размер, то не должно происходить и никакой реальной компоновки (freestanding), вся вещь компилируется как одна единица трансляции. Это будет один вызов GCC с кучей параметров.

Параметры компилятора

Вот основные параметры компилятора.

-std=gnu99 -Os -nostdlib -m32 -march=i386 -ffreestanding

Поскольку стандартные библиотеки не используются, то единственное различие между gnu99 и c99 заключается в отключенных триграфах (как и должно быть), и встроенный ассемблер можно записать как asm вместо __asm__ . Это не бином Ньютона. Проект будет настолько тесно связан с GCC, что я всё равно не озабочен расширениями GCC.

Параметр -Os насколько возможно уменьшает результат компиляции. Так и программа будет работать быстрее. Это важно с прицелом на DOSBox, потому что эмулятор по умолчанию работает медленно как машина 80-х. Я хочу вписаться в это ограничение. Если оптимизатор вызывает проблемы, то временно поставим -O0 , чтобы определить, тут ваша ошибка или оптимизатора.

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

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

Параметры -m32-march=i386 командуют компилятору выдавать код 80386. Если бы я писал загрузчик для современного компьютера, то прицел на 80686 тоже был бы нормальный, но DOSBox — это 80386.

Аргумент -ffreestanding требует, чтобы GCC не выдавал код, который обращается к функциям хелпера встроенной стандартной библиотеки. Иногда он вместо реально рабочего кода выдаёт код для вызова встроенной функции, особенно с математическими операторами. У меня это была одна из основных проблем с bcc, где такое поведение невозможно отключить. Такой параметр чаще всего используется при написании загрузчиков и ядер ОС. А теперь и досовских COM-файлов.

Параметры компоновщика

Параметр -Wl используется для передачи аргументов компоновщику ( ld ). Нам это нужно, поскольку мы всё делаем за один вызов GCC.

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

Параметр --script указывает, что мы хотим использовать особый скрипт компоновщика. Это позволяет точно разместить разделы ( text , data , bss , rodata ) нашей программы. Вот скрипт com.ld .

OUTPUT_FORMAT(binary) говорит не помещать это в файл ELF (или PE и т. д.). Компоновщик должен просто сбросить чистый код. COM-файл — это просто чистый код, то есть мы даём команду компоновщику создать файл COM!

Я говорил, что COM-файлы загружаются в адрес 0x0100 . Четвёртая строка смещает туда бинарник. Первый байт COM-файла по-прежнему остаётся первым байтом кода, но будет запускаться с этого смещения в памяти.

Далее следуют все разделы: text (программа), data (статичные данные), bss (данные с нулевой инициализацией), rodata (строки). Наконец, я отмечаю конец двоичного файла символом _heap . Это пригодится позже при написании sbrk() , когда мы закончим с “Hello, World”. Я указал выровнять _heap по 4 байтам.

Запуск программы

Компоновщик обычно знает нашу точку входа ( main ) и настраивает её для нас. Но поскольку мы запросили «двоичную» выдачу, то придётся разбираться самим. Если первой запустится функция print() , то выполнение программы начнётся с неё, что неправильно. Программе нужен небольшой заголовок для начала работы.

В скрипте компоновщика для таких вещей есть опция STARTUP , но мы для простоты внедрим её прямо в программу. Обычно подобные штуки называются crt0.o или Boot.o , на случай, если вы где-то на них наткнётесь. Наш код обязан начинаться с этого встроенного ассемблера, перед любыми включениями и тому подобным. DOS сделает за нас бóльшую часть установки, нам просто нужно перейти к точке входа.

.code16gcc сообщает ассемблеру, что мы собираемся работать в реальном режиме, так что он сделает правильную настройку. Несмотря на название, это не выдаст 16-битный код! Сначала вызывается функция dosmain , которую мы написали ранее. Затем он сообщает DOS с помощью функции 0x4C («закончить с кодом возврата»), что мы закончили, передавая код выхода в 1-байтовый регистр al (уже установленный функцией dosmain ). Этот встроенный ассемблер автоматически volatile , потому что не имеет входов и выходов.

Всё вместе

Вот вся программа на C.

Не буду повторять com.ld . Вот вызов GCC.

И его тестирование в DOSBox:

Тут если вы хотите красивой графики, то вопрос всего лишь в вызове прерывания и записи в память VGA. Если хотите звука, используйте прерывание PC Speaker. Я ещё не разобрался, как вызвать Sound Blaster. Именно с этого момента вырос DOS Defender.

Чтобы покрыть ещё одну тему, помните тот _heap ? Можем использовать его для реализации sbrk() и динамического выделения памяти в основном разделе программы. Это реальный режим и нет виртуальной памяти, поэтому можем писать в любую память, к которой мы можем обратиться в любой момент. Некоторые участки зарезервированы (например, нижняя и верхняя память) для оборудования. Так что реальной нужды в использовании sbrk() нет, но интересно попробовать.

Как обычно на x86, ваша программа и разделы находятся в нижней памяти (0x0100 в данном случае), а стек — в верхней (в нашем случае в районе 0xffff). В Unix-подобных системах память, возвращаемая malloc() , поступает из двух мест: sbrk() и mmap() . Что делает sbrk() , так это выделяет память чуть выше сегментов программы/данных, приращивая её «вверх» навстречу стеку. Каждый вызов sbrk() будет увеличивать это пространство (или оставлять его точно таким же). Данная память будет управляться malloc() и подобными.

Вот как можно реализовать sbrk() в программе COM. Обратите внимание, что нужно определить собственный size_t , потому что у нас нет стандартной библиотеки.

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

В процессе создания DOS Defender произошла интересная вещь. Я (неправильно) посчитал, что память от моего sbrk() обнулилась. Так было после первой игры. Однако DOS не обнуляет эту память между программами. Когда я снова запустил игру, она продолжилась точно там, где остановилась, потому что те же структуры данных с тем же содержимым были загружены на свои места. Довольно прикольное совпадение! Это часть того, что делает забавной эту встроенную платформу.

Расширение имени файла .COM не имеет отношения к доменному имени верхнего уровня .com (для "коммерческого") верхнего уровня. Однако это сходство в названии было использовано авторами вредоносных программ .

Содержание

двоичный формат DOS

Формат COM - это исходный двоичный исполняемый формат, используемый в CP / M (включая SCP и MSX-DOS ), а также DOS . Это очень просто; он не имеет заголовка (за исключением файлов CP / M 3) и не содержит стандартных метаданных , только код и данные. За эту простоту приходится платить: двоичный файл имеет максимальный размер 65 280 (FF00 h ) байтов (256 байтов меньше 64 КБ) и хранит весь свой код и данные в одном сегменте .

В архитектуре ЦП Intel 8080 можно было адресовать только 65 536 байт памяти (диапазон адресов от 0000h до FFFFh). При CP / M первые 256 байтов этой памяти, от 0000h до 00FFh, были зарезервированы для использования системой нулевой страницей , и любая пользовательская программа должна была быть загружена ровно в 0100h для выполнения. COM-файлы идеально подходят для этой модели. До появления MP / M и Concurrent CP / M не было возможности запускать более одной программы или команды одновременно: программа, загруженная в 01:00, была запущена, и нет другого.

В CP / M 3, если первый байт COM-файла - C9h, имеется 256-байтовый заголовок; поскольку C9h соответствует инструкции 8080 RET , это означает, что COM-файл будет немедленно завершен при запуске в более ранней версии CP / M, которая не поддерживает это расширение. (Поскольку наборы инструкций 8085 и Z80 являются надмножествами набора инструкций 8080, это работает на всех трех процессорах.) C9h является недопустимым кодом операции на 8088/8086, и это приведет к тому, что процессор сгенерировано исключение прерывания 6 в режиме v86 на 386 и более поздних чипах x86. Поскольку C9h - это код операции для LEAVE с 80188 / 80186 и, следовательно, не используется в качестве первой инструкции в допустимой программе, исполняемый загрузчик в некоторых версиях DOS отклоняет запускаемые COM-файлы. с C9h, чтобы избежать сбоя.

Большие программы

Поддержка платформ

Формат по-прежнему является исполняемым на многих современных платформах на основе Windows NT , но он запущен в MS-DOS -эмулирующей подсистеме, NTVDM , которая отсутствует в 64-битных вариантах. COM-файлы также могут выполняться в эмуляторах DOS, таких как DOSBox , на любой платформе, поддерживаемой этими эмуляторами.

Использование по соображениям совместимости

Параметры выполнения

Пользователь, желающий запустить foo.exe , может явно использовать полное имя файла:

Программы, которые поддерживают COM расширение файла

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

Программы, обслуживающие файл COM

Updated: 06/19/2020

Как открыть файл COM?

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

Шаг 1. Скачайте и установите Microsoft Windows

Шаг 2. Обновите Microsoft Windows до последней версии

Если у вас уже установлен Microsoft Windows в ваших системах и файлы COM по-прежнему не открываются должным образом, проверьте, установлена ли у вас последняя версия программного обеспечения. Разработчики программного обеспечения могут реализовать поддержку более современных форматов файлов в обновленных версиях своих продуктов. Это может быть одной из причин, по которой COM файлы не совместимы с Microsoft Windows. Самая последняя версия Microsoft Windows обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.

Шаг 3. Свяжите файлы DOS Command Format с Microsoft Windows

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

Процедура изменения программы по умолчанию в Windows

Нажатие правой кнопки мыши на COM откроет меню, из которого вы должны выбрать опцию Открыть с помощью
Нажмите Выбрать другое приложение и затем выберите опцию Еще приложения
Последний шаг - выбрать опцию Найти другое приложение на этом. указать путь к папке, в которой установлен Microsoft Windows. Теперь осталось только подтвердить свой выбор, выбрав Всегда использовать это приложение для открытия COM файлы и нажав ОК .

Процедура изменения программы по умолчанию в Mac OS

Шаг 4. Проверьте COM на наличие ошибок

Если проблема по-прежнему возникает после выполнения шагов 1-3, проверьте, является ли файл COM действительным. Отсутствие доступа к файлу может быть связано с различными проблемами.

1. Проверьте COM файл на наличие вирусов или вредоносных программ.

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

2. Убедитесь, что структура файла COM не повреждена

3. Убедитесь, что у вас есть соответствующие права доступа

Иногда для доступа к файлам пользователю необходимы права администратора. Переключитесь на учетную запись с необходимыми привилегиями и попробуйте снова открыть файл DOS Command Format.

4. Проверьте, может ли ваша система обрабатывать Microsoft Windows

5. Убедитесь, что ваша операционная система и драйверы обновлены

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

Вы хотите помочь?

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

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

С чего всё началось

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

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

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

Каждый WinAPI интерфейс позволяет сделать минимальное действие, которое может произвести ОС, то есть если программист решит написать приложение, то для его реализации придётся задействовать несколько сотен, а то и тысяч интерфейсов. Отдельно стоит упомянуть, что это далеко не единственный способ, который доступен в ОС для реализации алгоритмов. ОС Windows также предлагает компонентный подход для построения приложений. Это означает, что программист может объединять целые программы вместе, чтобы реализовать выполнение алгоритма. Возможно это за счет использования механизма Component Object Module.

Появление COM не случайно, реализация этого механизма — логичный этап развития. На схеме ниже можно увидеть ретроспективу создания механизмов в ОС Windows:

Картинка наглядно показывает, как связано появление того или иного механизма. Реализация каждого нового механизма это решение проблем, которые возникли при реализации предыдущего механизма. Картинка включает в себя такие механизмы как OLE, COM+, DCOM, которые тоже, надо сказать очень сложные с точки зрения реализации и изучения.

Некоторые полезные определения

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

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

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

DCOM - механизм, который предоставляет возможность работать с объектами COM в рамках локальной сети или Интернета.

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

Примеры и практика

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

Для исследования был выбран вот этот документ. Он представляет собой docx файл, по сути это архив, который содержит некоторое количество файлов с инструкциями, как его рендерить. Заглянем внутрь: в этом формате все данные, которые могут быть добавлены через OLE это файлы, которые расположены в директории "word/embeddings". Заголовок содержимого объекта можно видеть ниже:

Ничего особенно примечательного, такие объекты можно анализировать с использованием набор инструментов oletools.

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

Объект COM - представление зависит от типа предоставляемого функционала, чаще всего в программном обеспечении используется в совокупности с WinAPI CoCreateInstance. Визуально исследовать объекты можно через относительно простой инструмент - COMView. Пример работы инструмента:

Почти все элементы пользовательского интерфейса, которыми мы пользуемся каждый день, это COM объекты.

Как найти объекты COM+? Если в COMView вы обнаружили объект, который имеет интерфейс IUnknown, перед вами COM+ объект. Например:

Таким образом можно установить, за какой функционал отвечает тот или иной объект, который используется программным обеспечением. При этом не нужно вникать в имплементацию и можно сразу разобраться в алгоритме приложения, прочитав описание объекта в интерфейсе COMView.

Статья подготовлена Александром Колесниковым в рамках курса "Reverse-Engineering. Professional". Если интересно узнать больше о программе и формате обучения на этом курсе, приходите на день открытых дверей онлайн, на котором вы также сможете познакомиться с преподавателем.

COM filename extension is associated with files used in various Microsoft operating systems, from to MD-DOS to Windows Millennium.

Windows

Mac OS

Как открыть COM файлы

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

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

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

Возможные проблемы с файлами в формате COM

Отсутствие возможности открытия и работы с файлом COM, совсем не должен значить, что мы не имеем установленного на своем компьютере соответствующего программного обеспечения. Могут выступать другие проблемы, которые также блокируют нам возможность работы с файлом Command Executable Format. Ниже находится список возможных проблем.

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

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