узнать размер бинарника до компиляции

но если компилять без оптимизаций и знать количество 0 и 1?

не поможет.

Ну, на одних .com файлах далеко не уедешь, так что exe файлов там вполне хватало :)

• На 16 бит данные лучше располагать по адресам, кратным 2;
• На 32 бит данные лучше располагать по адресам, кратным 4;
• На 64 бит данные лучше располагать по адресам, кратным 8.

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

Одно могу точно сказать - .com файлы исполняемые так уже точно нельзя было заразить :)

лолшто? Можно было хитровы-нно прописаться хоть в DATA. Способы всегда можно найти. Спасает только MD5 всякие.

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

и как же это может быть?

ну вот strip срезает 40 килобайт с 120 килобайтного бинарника. значит без стрипа мы получаем 40 килобайт места под что-нибудь

а где у .com DATA? Это же по сути был поток исполняемых инструкций без какого-либо заголовка, с произвольной абсолютно структурой внутри, с тем только ограничением что не больше 64к, и с обещанием что код начнется со смещения $100, вроде все... Или я что-то уже забыл?

а где у .com DATA? Это же по сути был поток исполняемых инструкций без какого-либо заголовка, с произвольной абсолютно структурой внутри, с тем только ограничением что не больше 64к, и с обещанием что код начнется со смещения $100, вроде все... Или я что-то уже забыл?

ничего ты не забыл. я под DATA имел в виду данные com-файла. Они ж там должны быть какие-нибудь.

Но в общем-то ты прав. В com влезть труднее. Но были вирусы, которые и в com влазили так, что не заметишь.

Можно попробовать поискать какой-нибудь примитивный компилятор языка C (не обязательно поддерживающий 100% всех возможностей языка), написанный на асме. Может есть где, кто курсовую может делал :) Скомпилировать, потом дизассемблировать и глазками убедится, что инструкции совпадают с исходником. Если так - значит выхлопу этого компилятора можно относительно доверять. Берем другой какой-нибудь C компилятор, более продвинутый, но простой, написанный на C, глазками изучаем весь код, на наличие бэк-доров. Если все ок - то еще неделю дорабатываем код, что-бы оно скомпилировалось первым компилятором, и в итоге плучаем компилятор N2, выхлопу которого тоже можем относительно доверять, но который уже умеет большую часть С стандарта. И далее, запасаемся едой на пару лет, изучаем код gcc на бэкдоры, если все ок, компилируем gcc компилятором N2, и на выходе - получаем gcc, выхлопу которого можно относительно доверять.

Вот как-то так например..

а что-нибудь проще? например какая-нибудь обратная компиляция - если мы знаем всё что делал компилятор (т.к тока что скомпиляли), взять и сделать всё в обратном порядке?

Это ты сейчас решил бинарник в исходник декомпилировать?

типо того

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

ЗЫ - если уж параноить, то начинать надо с проверки на бэкдоры процессора, а это никак не сделать, без открытых спеков, так что - мы вынуждены так или иначе, доверять вендорам разным итп... Или не пользоватся техникой никакой цифровой вообще.

при _наличии_ опыта..

а если как-то запротоколировать ВСЁ что делал компилятор, а потом повернуть вспять? или я что-то не понимаю? или оно всё равно так выдаст изначальный исходник до внедрения червя?

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

сторонняя тулза для дизассемблирования, и вуаля. Некоторым особо одаренным хватало hex-просмотрщика редактора, который встроен в любой файловый менеджер :)

а если как-то запротоколировать ВСЁ

Потренируйся на dmesg, для начала. Попробуй объяснить ВСЕ сообщения.

Потренируйся на dmesg, для начала. Попробуй объяснить ВСЕ сообщения.

ты так говоришь, будто это не реально. Линус наверняка это может, а значит и другие [когда-нибудь] смогут

Там десятки модулей загружаются. Линус их в глаза не видел.

когда мы попытаемся сравнить содерижимое исполняемого файла с кодами на листочке мы получим одинаковые программы.

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

мне чудятся ацетоновые бобры

нет.

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

http://cm.bell-labs.com/who/ken/trust.html

Затем

http://www.dwheeler.com/trusting-trust/

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

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

А при чём тут информатика? Она с компьютерами напрямую не связана.

teod0r> убедиться в чистоте будущей системы

Собери всё сам.

Проведи компеляцию вручную на бумажке.

что нибуть типо tcc(в плане лапидарности исходного кода и самокомпелируемости) тогда берёш.

твой сс=tcc ( здесь и далее в общем можеш чё другое взять)

1. анализируеш исходный код сс согласно твоему_определению(K&R,C89,C99, что нить реализации_зависимое отднако как не страно K&R + некоторые конкретизации(устранение двухсмысленностей) из С89( но не весь С89 ибо это дитя комитета и внём есть много бюрократически добавленного уже)) входного языка(С) и той операционой среды которое потребна компилятору . 2. после удостоверения что нет закладок вручную переводиш в маш код ( здесь можно отключить все оптимизации т.е компилировать не крутейший а достаточный компилятор) - затем далее по вилеру.

этого не всегда достаточно - необходимо ещё анализировать сырцы и инструмент сборки на предмет закладок - что просто напросто очень дорого - поэтому верим .

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

тут вот в ч1м заковыка : если встройщик_кода знает как верифицируется носитель то либо находится метод компроментации и верификация бесполезна либо оказывается что так верифицировать очень дорого ибо всякая функция у которой область значений меньше области определения в теории абсолютно не_стойка - т.е ключ верификации обязан быть равномощен сообщению - короче подсчёт 0 и 1 не спасает :)

qulinxao> этого не всегда достаточно - необходимо ещё анализировать сырцы и инструмент сборки на предмет закладок - что просто напросто очень дорого

Вообще говоря, это реально. Пишем скрипт, который анализирует исходники путём выискивания подозрительных мест. Далее полуручным методом просматриваем подозрительные участки (особенно качается тех, которые типа однострочника на PERL).

неа. в .com нет гарантированного «пустого» места - а так при должном усилии начиная с определённого размера ( около 7 кб возможно) и с некоторого времени ( когда .сom как правило стали результатом компиляции hll) c этого времени ситуации таже - полно мест куда воткнуть.

вы получите/укрепитесь в уверености и только. это не гарантирует отсутствия. в месте с тем для гарантии отсутствия неожиданостей нужно начинать чуть раньше - с транзисторов :) в этом случае авторы неожиданостей будут заведо не_люди.

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

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

а если вирус не только в компиляторе, но и в ядре?

Если вирус в ядре ОС, то какая разница, интерпретируется программа налету, или была заранее скомпилирована?

неужели никто до сих пор не создал компьютера с чистым компилятором ради безопасности всего мира?

Ты бредишь.

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

приметивных

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