Длина командной строки и пути к файлу при запуске

Internal structure and you change requests/suggestions
  • Freeman
    1.Зачем экспорт, длл в pe формате. Велосипед изобретаем только для екзешников.
    2.Явно начало секции указано только для import, что необходимо. Если ecode выравнен на страницу, секция кода может быть защищена от записи, остальные соответственно от исполнения. eimport и edata похоже действительно лишние. Файл приложения это образ в памяти, никаких секций, смещённых относительно своих виртуальных адресов. Если выравнивание требует заполнение промежутков, значит там будут nop-ы.
  • 1. Зачем два формата?
    2. Необходимо кому? Процессор этого не требует, значит этого требует программист. Назови его имя.

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

    У меня написана утилита для работы с образами PE, которую можно было бы научить сохранять и в MENUET01, и в KOLIBRI, делая rebase и перетасовывая секции как нужно. Думал создать для нее тему.
    Serge wrote:Если ecode выравнен на страницу, секция кода может быть защищена от записи, остальные соответственно от исполнения. eimport и edata похоже действительно лишние. Файл приложения это образ в памяти
    Ты уж определись: или образ в памяти, или защита. Предположим, у меня есть 600 байт кода, 40 байт данных и еще 600 байт импорта. Если файл -- образ в памяти, с заголовком выходит 1288 байт. Если же при этом нужна защита, имеется три секции: код с защитой от записи, данные с защитой от исполнения и импорты с защитой от (чего?). При 4 КБ на страницу получаем файл размером 12336 байт, если он по-прежнему образ в памяти. Разве не так? Ни фига себе "Колибри"!

    Добавлено: Впрочем, даже в PE выравнивание в файле и в памяти может отличаться...

    Я подразумевал, что если загрузчик знает размеры секций, он их сможет растасовать их по страницам, которые и займут в памяти 12 КБ, а файл при этом останется 1288 байт, что более привычно для "Колибри".

    Если код и импорты с экспортами имеют одни и те же флаги защиты, их можно объединить, тогда надо еще подумать, как это наиболее технологично сделать.

    Добавлено: Неожиданно быстро удалось прикрутить сохранялку в формат KOLIBRI (концепт). Порядок секций такой же, как в описании: код, импорты, экспорты, данные. Rebase не делается, image base прописывается исходный. Вызывать:

    Code: Select all

    pet my.dll -into my -kolibri -strip -trunc
    
    В режиме -strip выравнивание не делается, иначе выравнивается на 8 байт. Ключ -trunc запрещает выравнивать последнюю секцию (данные).
    Attachments
    Pet.7z (20.16 KiB)
    Downloaded 381 times
  • Freeman wrote:Ты уж определись: или образ в памяти, или защита. Предположим, у меня есть 600 байт кода, 40 байт данных и еще 600 байт импорта. Если файл -- образ в памяти, с заголовком выходит 1288 байт. Если же при этом нужна защита, имеется три секции: код с защитой от записи, данные с защитой от исполнения и импорты с защитой от (чего?).
    Импорт с защитой от исполнения. Не нужно всем секциям страничное выравнивание, достаточно код от всего остального отделить. И не хочется делать многосекционный файл, чтобы потом каждую секцию на своё место копировать. Экономия дискового пространства копеечная, а файл традиционно будет сжат kpack.
    Утилита это хорошо, но есть порт ld, генерирующий бинарник в родном формате Колибри. Обновить его под новый заголовок дело на один вечер. А для fasm пара макросов нужна. Хотя, если таким образом конвертировать PE других компиляторов, будет неплохо.
  • Serge wrote:Не нужно всем секциям страничное выравнивание, достаточно код от всего остального отделить.
    Да, я потом уже вспомнил, что раз в PE выравнивание в файле отличается от страничного, то можно как-то по-другому.
    Serge wrote:И не хочется делать многосекционный файл, чтобы потом каждую секцию на своё место копировать. Экономия дискового пространства копеечная, а файл традиционно будет сжат kpack.
    А ты пока не копируй, оставь на вторую версию. :lol: Мне кажется, что если уж принимать новый формат, в нем должен быть потенциал для роста. Не куча мусора, как в PE, но минимальная дополнительная инфа должна присутствовать. В будущем ее можно будет интерпретировать как-то по-другому.

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

    Поскольку моя версия заголовка получилась размером 60 байт, наверное, ее стоит дополнить еще одним зарезервированным двойным словом в конце, чтоб уж 64 было. Сейчас 64 байта заголовок имеет только при включенном выравнивании, что мне кажется в стиле "Колибри".
    Serge wrote:Хотя, если таким образом конвертировать PE других компиляторов, будет неплохо.
    Да-да, и я о том же. Нужно только формат утвердить. Видеть PE в качестве основного формата "Колибри" мне не хотелось бы. Это и к имиджу минус, и проблем с антивирусами не избежать.

    MENUET01 для обратной совместимости останется? Со временем его тоже в Pet добавлю тогда.
  • Freeman
    Обратная совместимость это святое.
    Про флаг консольного приложения тоже думал. Секцию экспорта можно добавить, хотя зачем она в экзешнике ? Ещё есть желание добавить .debug секции, но тут надо с форматом разбираться.
  • Serge wrote:Секцию экспорта можно добавить, хотя зачем она в экзешнике ?
    Так я же писал. Размер секции экспорта равен 0 -- приложение, ненулевой размер -- библиотека. Подбиваю тебя на единый формат для приложений и библиотек. ;)

    Размер секции с отладочной инфой можно тоже добавить -- как раз последние 4 байта остались до 64.

    Еще думал, как вместить перемещаемые символы (релоки), если понадобится для библиотек. Наверное, нужно добавить флаг (в те самые три байта), и тогда трактовать поле ImageBase как размер секции релоков, а фактический ImageBase в таком хранить уже в секции релоков, в ее заголовке.
  • Подбиваю тебя на единый формат для приложений и библиотек.
    С fasm будет облом. Придётся править исходники, чтобы таблицу релокаций в файл записать. И не уверен я в необходимости единого формата.
  • Serge wrote:С fasm будет облом. Придётся править исходники, чтобы таблицу релокаций в файл записать.
    Я уже понял, что для библиотек PE избежать не удастся, по крайней мере, пока. Использование неродного формата будет печалить, и единый собственный формат -- надежда на будущее, цель развития. Поэтому и нужен мини-PE без мусора, чтобы хоть через утилиту в него преобразовывать.
  • Who is online

    Users browsing this forum: No registered users and 6 guests