загрузка и запуск неродного формата (например, ELF) в windows
Sbtrn. Devil
Подскажите, граждане — реально ли написать для виндовса вручную загрузчик и запускатор какого-нибудь неродного формата (например, ELF)?
>soflot: есть такое мнение, что при наличии прямых рук, светлой головы и обилии мануалов теориетически можно
Sbtrn. Devil
Это не вопрос прямых рук (. ). Дело в том, что специалисты в окрестностях меня высказывали мнение на предмет следующего: низзя, мол, создать сегмента с кодовыми правами выполнения из-под процесса юзерского уровня. Ибо это, мол, привилегия ядра системы. Ибо, мол, в противном случае был бы беспредел и рай для вирусов.
(. )
«в тупую» запускать код нельзя. А если сделать эмулятор, то можно. Если сильно исхитриться и заменять все ОС-зависимые участки кода этого файла неродного формата на аналогичные участки кода родного формата ОС, то наверно тоже можно (хотя это для гениев/безумцев)
>низзя, мол, создать сегмента с кодовыми правами выполнения из-под процесса юзерского уровня.
Это гон.
Код уже загруженный в память активно изменяется разными программами, например отладчиком.
Thunks вполне работают.
VirtualProtect позволяет совершенно свободно разрешить выполнение кода с любой страницы VM.
Конишуа
>Это гон.
>Код уже загруженный в память активно изменяется разными программами, например
>отладчиком.
>Thunks вполне работают.
>VirtualProtect позволяет совершенно свободно разрешить выполнение кода с любой
>страницы VM.
Т. е., можно сделать так:
void *codepage = VirtualAlloc(хачу_адрес,хачу_размер,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
FILE *f = fopen («my_super_format_code.xxx»,»rb»);
int (*entry_point) (int,char**) = MySuperLoader (codepage,xxx);
entry_point (argc,argv);
и будет щастье, и ничего нам за это не будет?
Даже больше. У старых x86 нет флажка NoExecute. Так что VirtualProtect что-то там защищает на исполнение с каких-то там сервиспаков XP и на новых CPU, не по дефолту. По дефолту и так все открыто.
Проблемы нет взять и отмапить elf в память, а потом выдать ему управление. Проблема есть в том что elf файл в своей линк-секции наверняка захочет поиспользовать какие-нибудь динамические библиотеки. Надо будет их поднимать и линковать. Если ограничиться libc.so ( скомпилировать под Windows libc.dll и звать функции оттуда ) — то пожалуй хорошее упражнение. Пожалуй «Hello World» можно поднять за пару дней.
На мой взгляд — можно. Я например писал эдакое извращение — делегаты для WinAPI:
1) Выделял память (HeapAlloc . )
2) Запихивал туда код:
Вот ссылка, прадва про загрузку PE и DLL но может помочь.
Ну, формат-то можно сделать и свой, который не требует для линкажа чего-нибудь сверхъестественного.
У меня ведь почему такой праздный интерес. Зародилась такая теоретическая идея на предмет повышения кросс-ОСности игр (в принципе, не только, но с играми проще всего, ибо они (кроме отмороженных сапёров, ессно) не используют стандартный ОС-зависимый юзер-интерфейс, поэтому не требуют дизайновых изменений при переносе на другой бакэнд). Смысл:
1) Взаимодействие софта со служебными сервисами (графика, звук, файлы и пр.) идёт не через систему, а через вызовы в некий фрамеворк собственного авторства, реализованные через «вызов функции по указателю, который сообщён при запуске».
2) На каждой интересующей нас ОС делается по реализации фрамеворка.
3) Выполнябельный код держится в тех самых исполняемых файлах собственного формата, а фрамеворк умеет их грузить. Причём, реализации таковы, что фрамеворк с разных ОС, но на одинаковой процессорной платформе распознает один и тот же исполняемый файл одинаково. Патчи для одной и той же проц. платформы, соответственно, тоже универсальные. (Если только какие-нть ОСы не пользуют процессор в совсем уж нестандартном режиме, но таких на компутере среднестатистического юзера или не стоит, или (ДОС) позволяется менять режим процессора в любой нужный.)
4) Версии фрамеворка для наиболее общеупотребительных ОС могут входить в стандартный комплект поставки, а для остальных могут фриварно скачиваться с суппортного сайта производителя софта (оттуда же и фреймворкные патчи).
Таким образом, можно достичь всяких полезных результатов. Например, охватить более широкую аудиторию при существенно меньших затратах, чем если бы пришлось сочинять по порту программы на каждую ОС. (Естественно, это проявится за счёт того, что фрамеворк можно реюзать в многих продуктах.) А фрамеворк можно сделать отдельным продуктом и делать на нём отдельный бизнес (завлекать народ распространением бесплатных СДК, продавать лицензии, и т. п.)
Запустить ELF под Windows вполне реально и довольно прость.
Одно время я хотел написать Wine-подобный эмулятор linux под windows, но проект быстро загнулся из-за полной невостребованности.
Пример с исходниками тут:
http://orbides.1gb.ru/orbf/linsys-0709xx.zip
Запускает довольно простые программы, самая сложная — ассемблер fasm.
Правка+:
Sbtrn. Devil
4) Версии фрамеворка для наиболее общеупотребительных ОС могут входить в стандартный комплект поставки, а для остальных могут фриварно скачиваться с суппортного сайта производителя софта (оттуда же и фреймворкные патчи).
Таким образом, можно достичь всяких полезных результатов. Например, охватить более широкую аудиторию при существенно меньших затратах, чем если бы пришлось сочинять по порту программы на каждую ОС. (Естественно, это проявится за счёт того, что фрамеворк можно реюзать в многих продуктах.) А фрамеворк можно сделать отдельным продуктом и делать на нём отдельный бизнес (завлекать народ распространением бесплатных СДК, продавать лицензии, и т. п.)
Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то хорошая, только вот кто же этим не через Ж займётся?
Какие преимущества, кроме того что собирается один-единственный бинарник для разных платформ? Этот кросплатформенный layer можно попробовать вынести в библиотеку, тот же самый результат только проще. Думаю очевидно, что твоя идея идет лесом если должны поддерживаться несовместимые архитектуры процессоров.
Конишуа
>Какие преимущества, кроме того что собирается один-единственный бинарник для
>разных платформ? Этот кросплатформенный layer можно попробовать вынести в
>библиотеку, тот же самый результат только проще.
А унифицированный бинарник — это не так уж и мало. 8) Помимо той стороны, про которую я уже сказал, есть и ещё.
1) Допустим, в круг наших интересов включается новый ОС (на том же процессоре, ессно). Портируем на него фрамеворк, и.
— если оно было прилинковано библиотекой, все ранее написанные программы, которые использовали наш фрамеворк, для портации под новый ос придётся переделывать каждую.
— если оно было через унифицированный бинарник, все ранее написанные программы автоматически готовы к употреблению — юзеру только нужно качнуть и поставить фрамеворк.
2) Фрамеворк, помимо всего, может включать и свою собственную поддержку инсталляции, предназначенную для работающих под него программ. Естественно, тоже унифицированную. А это значит, что у нас единый не только бинарник, но и весь дистрибутив. То есть, можно собрать один и тот же дистрибутивный сидюк и распространять его на общих основаниях, и будет он иметь смысл и для виндузоидов, хоть для линуксоидов, и даже и для пользователей тех осов, которые мы пока ещё не включили в круг интересов, но собираемся. А это уже посерьёзнее.
>Думаю очевидно, что твоя идея
>идет лесом если должны поддерживаться несовместимые архитектуры процессоров.
Тут да. Но, учитывая, что процессорная архитектура у целевой аудитории практически одинаковая. 🙂
>Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то
>хорошая, только вот кто же этим не через Ж займётся?
Да идеи у мелко$офта вообще хорошие (в истоках). Но они извращаются и губятся на корню через жадность и тщеславие.
Sbtrn. Devil
>> Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то хорошая, только вот кто же этим не через Ж займётся?
> Да идеи у мелко$офта вообще хорошие (в истоках). Но они извращаются и губятся на корню через жадность и тщеславие.
Чем лучше идея, тем проще её изгадить. 🙁
идея эта уже реализована, только называется Wine и запускает виндовские приложения под линуксом
O01eg
> идея эта уже реализована, только называется Wine и запускает виндовские приложения под линуксом
Очередной намёк на то, что линукс круче всех? :/
Здесь, насколько я понял, речь идёт не о запуске софта для одной ОС на другой ОС (виндовские под *nix или наоборот, неважно), а о том, чтобы скомпилить 1 исполняемый файл и запускать его на любой системе.
Dinosaur
>Здесь, насколько я понял, речь идёт не о запуске софта для одной ОС на другой ОС (виндовские под *nix или наоборот, неважно), а о том, чтобы скомпилить 1 исполняемый файл и запускать его на любой системе.
А в чём разница? В том, что необходим внешний loader? Так он в любом случае понадобится
keltar
Просто мне показалось, что смысл поста O01eg‘а был что-то вроде «есть же Wine и нефиг велосипед изобретать». Возможно, я его не так понял.
COFF в Linux или ELF в Windows
можно ли запускать исполняемые файлы COFF в UNIX или исполняемые файлы ELF в Windows? И каковы будут шаги, чтобы иметь возможность запускать любой тип файла в Windows и UNIX. Мне просто любопытно.
4 ответов
чтобы фактически запускать исполняемые файлы и заставлять их делать полезные вещи, вам нужно беспокоиться об API, а не только о формате исполняемого файла. На машине Linux с установленным WINE можно запустить Windows .EXE-файлы из командной строки, и они делают то же самое, что и в Windows.
другой путь на самом деле не представляется возможным, однако если вы установите CYGWIN на машине Windows, а затем перестроить приложение из исходного кода с помощью компиляторов CYGWIN, вы получите исполняемый файл, который работает в Windows и делает то же самое, что и исполняемый файл Linux в Linux. Многие стандартные инструменты Linux уже портированы и находятся в репозитории CYGWIN, включая X-Windows и GIMP.
http://lbw.sourceforge.net/ работает лучше, чем линия. Лоу был еще одним проектом для того, чтобы делать то же самое, но это было менее эффективно.
EDIT:http://atratus.org/ кажется, что делает то же самое, без необходимости иметь Interix/SFU.
чтобы правильно ответить на ваш вопрос, важно рассмотреть, что такое ELF, COFF и PE. Эти двоичные форматы по существу просто контейнеры, которые дают указания операционной системе о том, как выполнить инструкции raw CPU, содержащиеся в файле. Они очень похожи на аудио / видео контейнеры, такие как MKV, WMV и OGG. Поддержка исполняемого формата находится либо в операционной системе, либо нет. Microsoft Windows последовательно не оказывает никакой поддержки COFF или ELF, пока недавно. С Windows 10 Microsoft оказала косвенную поддержку ELF, встроив в системные подпрограммы, совместимые с Windows kernel UserMode-Linux. Ядро UserMode Linux работает поверх ядра Windows и запускает все двоичные форматы ELF почти так, как если бы оно работало независимо от MS Windows.
альтернатива использованию UserMode-Linux (sub-kernel) для Microsoft переписать большинство API Linux в полностью совместимом формате, их выбор решает один другая проблема совместимости:API-интерфейс. «A» означает Приложение, А» I » — интерфейс, однако API как интерфейс-это в основном набор исполняемых подпрограмм и предположений среды. Доступ к файловой системе и большинству основных системных подпрограмм обеспечивается ядром Windows, а все остальное-ядром UserMode Linux. Таким образом, Windows может не только запускать исполняемые файлы в формате ELF, но и запускать самые популярные исполняемые файлы ELF, которые уже сделаны для запуска на Linux API.
обратная, другая половина вопроса, запуск PE (большинство исполняемых файлов Microsoft Windows) в Linux также возможен. Существует две библиотеки обертывания среды выполнения, которые могут запускать MSIL (приложение виртуальной машины) и Win32 (обычное приложение ЦП). Поскольку ядро Linux расширяемо для распознавания определенного формата байтов, а затем запускает соответствующую программу-оболочку, ядро поддерживает PE и потенциально более исполняемые форматы контейнеров. Поэтому Linux может запускать некоторые PE-программы либо в mono runtime (приложения .NET/C#), либо в Wine runtime (Win32 C / C++).
чтобы установить среду UserMode-Linux, вы можете следовать инструкциям, приведенным на сеть разработки Microsoft. Подводя итог:
- включить Режим разработчика: Настройки / Обновление и безопасность / для разработчиков / Проверьте переключатель Режим разработчика
- в меню «Пуск» откройте » включить функции Windows on или off»
- прокрутите вниз и проверьте функцию» Подсистема Windows для Linux (бета-версия)»
- нажмите » ОК » и перезагрузитесь (необходимый шаг)
- после перезагрузки откройте Командную строку PowerShell / и запустите «Bash» и следуйте простым подсказкам, чтобы принять лицензию Canonical и начать загрузку образа Ubuntu
- после завершения загрузки вы сможете запустить «Bash on Ubuntu on Windows» из меню «Пуск»
будьте в курсе этот метод работает только в Windows 10 и по-прежнему ограничен текстовой консолью и портом Win32 Xorg, таким как vcXsrv, для чего-либо графического. Системы Cygwin или MSYS2 не могут запускать двоичные файлы ELF, но позволяют переносить и запускать те же приложения, которые обычно являются двоичными файлами ELF в системе Linux.
COFF был первоначально представлен UNIX (вокруг System V или около того), Поэтому да, некоторые UNIX, вероятно, все еще поддерживают формат COFF. Это было устарело Linux, по крайней мере, на некоторое время, и, по-видимому, большинство других Unices также устарели или полностью отказались от поддержки.
поддержка Windows ELF немного более сомнительна — почти наверняка не существует без какой-то глубокой хитрости. Вы должны быть более конкретными о том, что вы пытаетесь сделать здесь.
GCC:Компиляция в формат elf под Windows
Компиляция GCC в Windows
У меня в виндусе GCC для виндуса (портированный) Я хочю на нем (5,1) скомпилировать сам.
Gas, создающий ELF, но работающий из-под Windows
Нужен gas (GNU Assembler), работающий из-под Windows, но создающий ELF. У меня есть MinGW, но даже.
Раздельная компиляция nasm+gcc для подсистемы Debian в Windows 10
Я сейчас активировал подсистему линукс в винде 10, установил из Mic.Store «Debian». Установил.
Чем открыть формат файла *.Elf
Как открыть формат файла
AJIEKC, elf — это формат исполняемого файла в юниксовых системах. Что-то вроде аналога exe-файлов в виндовсе. Но в юниксовых системах расширение файла не имеет значения и там исполняемые файлы обычно бывают без расширения.
Проще говоря автор спрашивает: можно ли под виндовсом скомпилировать программу для использования в линуксе.
Устанавливаем Cygwin, в ней компилируем gcc (не mingw) с помощью компилятора от Cygwin.
Получаем gcc, который компилирует в elf файлы, но работает под Cygwin.
На практике не испытывал.
It should be possible. You just have to download the sources of Linux
(the kernel, not GNU/Linux, the whole system), glibc and GCC, get the
headers of the kernel and glibc somewhere GCC can find them, and build
GCC as a cross compiler, then use it to build glibc.
I’ve never seen anyone do it on MS-Windows, and in fact I think it
would be a stupid thing to do, but it’s certainly possible.
gcc правда собирать — пол дня убить
Добавлено через 3 минуты
Евгений М., чтот я сомневаюсь, cygwin только эмулирует окружение, все программы скомпилены в PE, если не путаю
Добавлено через 9 минут
http://gcc.gnu.org/install/build.html
там есть раздел cross compiler
я вообще только готовыми пользовался, так что расскажите, что да как
Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь.
Собрать компилятор gcc с gtk+ под Windows 8.1
Всем доброго в.с. Необходимо поднять существующий проект написанный на C++. О проекте известно.
Компиляция под андроид из под Windows 10
Всем привет. У меня есть проект, реализованный с использованием QML + Qt 5.5.1 Он отлично.
Компиляция под Windows 95
Подскажите, можно ли на откомпилировать проект на XE6 так, чтобы программа работала на Windows 95.
Компиляция под Windows из Linux
Компиляция под Windows из Linux — возможно ли это? По идее как-то можно с MinGW, есть у кого опыт?