как подсчитать контрольную сумму сегмента кода?

А дампы нельзя сделать и поглазеть отладчиком, что внутри?

PIC это про контроллер?

А дампы нельзя сделать

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

PIC это position independent code

Какие-то азы есть по http://linuxgazette.net/112/krishnakumar.html,

Похоже mm_struct это то что нужно.

Хм, подробнее про проблему можно? А то как-то я не особо сталкивался с таким. На голом железе в принципе не проблема понять где начало _text, а где конец и снять чексумму. А вот под OS как - х.з. запилишь - напиши решение сюда

да я думаю без дампов можно обойтись

То есть вместо того, чтобы точно выяснить, где косяк, ты хочешь контрольными суммами выяснить, что косяк есть? Или у меня тоже башка не варит :(

Я думаю /proc/self/maps это то что надо. К сожалению, я мало что во всём этом понимаю, но, вроде, тут всё просто. По крайней мере где стэк, где код, а где heap понятно.

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

чтобы точно выяснить, где косяк

я хочу просто встроить проверку целостности в программу. Не с целью обойти дебаггеры или антихаков понаставить. Просто sanity-check.

Ух ты, да, действительно удобно, все есть.

В принципе тогда можно делать чексумму text, которую сравнивать с заведомо известным значением в rodata. Чексуммер делается просто: делаем objcopy секции text, прогоняем через crc32sum или что-то иное, сохраняем в хедер, так чтобы оно попало в rodata, и докомпиливаем заново. Ну и в рантайме делаем проверку.

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

да, я думаю не стоит расчитывать что всё останется на месте. Но вот для отдельных символов подсчитать же можно контрольные суммы? Чую, терминология хромает, но смысл понятен.

я думаю из-за PIC каждый раз всё будет по разным адресам.

вернее, из-за http://en.wikipedia.org/wiki/Address_space_layout_randomization

Для отдельный статически инициализированных НЕ нулем переменных?
Это лезет в data, емнип.
Еще можно в мейне проверить bss на предмет все ли забито нулями. Это делает стартап код, но если память битая - все может быть.

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

Тебе пофиг куда сложится text

так он каждый раз разный будет. Сделай несколько раз подряд cat /proc/self/maps и сравни :)

По-моему, за это отвечает kernel.randomize_va_space

А ничего, что код может меняться в рантайме загрузчиком?

Причем здесь антихаки?

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

А по ссылке, как я понял, разжёвывается элементарная т.н. силовая отладка. Я сам ей пользуюсь, когда контроллеры отлаживаю. Ибо, jtag не панацея. Но у тебя ведь не 8битный ЦП с 8 кб памяти?

А ничего, что код может меняться в рантайме загрузчиком?

я так понимаю это в двух случаях: при -z lazy и когда, скажем, делает dlopen. В остальных случаях в багдаде всё спокойно, верно?

Конечно, проверки должны делаться с учётом этого.

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

когда проги на ровном месте сегфолтились,

[вещества] [SICP] В глюках наших компьютеров виновато космическое излучение? (комментарий)

Карма, она такая.

С целевой тачки тебе нужен только дамп! Храни у себя точно тот же бинарь и запускай отладчик на своей машине же.

Хм, а что реально он может там поменять? Ссыль в студию.

Всегда, когда бинарник грузится по другому адресу, чем было задано при линковке. Как это в линуксах конкретно работает (и работает ли вообще) я не в курсе...

Насколько помню, это ж вроде рандомизует по каким вирт адресам положат секции, но сами их не разбивает никак.

Карма, она такая.

Железо такое, буду менять.

Ну вот: http://en.wikipedia.org/wiki/Relocation_(computer_science)

а что реально он может там поменять?

dlopen :)

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

С целевой тачки тебе нужен только дамп!

да не нужен никакой дамп :). Читаешь /proc/self/maps, дальше md5sum(start_address, len). И усё.

Всего за полгода убедился в существовании хардварных багов. Растешь.

ты тоже не понимаешь теорию вероятностей и поверил в то что написано в том пейпре? Хотя, не похоже что ты его даже открывал.

Не совсем пока уверен, что это именно в text находится, насколько помню это в .plt/.got.plt
Вот ман, а я пошел спать. Утром тред гляну.
http://em386.blogspot.com/2006/10/resolving-elf-relocation-name-symbols.html

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

У меня как-то mplayer глючил. При перемотке падали X. Что я сделал? Компильнул его в отладочном режиме и дождался очередного падения. Натравил gdb на дамп и он мне сказал, что последняя вызванная функция была что-то вроде snd_seek. Я нашел эту функцию. Параллельно погуглил и узнал, что у меня глючная звуковушка (а я уже понял куда копать). В результате я вставил туда дополнительную переинициализация и усе.

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

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

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

Нашёл пейпр по «Dynamic Code Checksum Generator» который вроде как учитывает adress space randomization. Правда, там речь о виндах, но всё равно любопытно почитать.

А вот и практически готовое решение: http://unix.stackexchange.com/questions/6301/how-do-i-read-from-proc-pid-mem-...

какого сегмента - сегмента исполняемого файла (elf), сегмента кода в архитектуре x86 (который в линуксе всегда от 0 до 4Гб)?

Наверно тут свои проблемы внесёт PIC

наоборот, там код не должен зависеть от адреса, по которому его загрузили, соотв. везде используется относительная адресация

сегмента исполняемого файла (elf), сегмента кода в архитектуре x86 (который в линуксе всегда от 0 до 4Гб)?

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

Текстовый сегмент может быть зашифрован. Это надо учитывать в общем случае.

Изначально я планировал делать проверку целостности для своих программ. Но ты подал идею :). Хотя, наверняка антивири такое умеют.

В общем, по мотивам ссылки выше:

#! /usr/bin/env python3
import hashlib
import re

r = re.compile(r'(?P<start>[0-9A-Fa-f]+)-(?P<end>[0-9A-Fa-f]+) (?P<perm>\S+) (?P<off>\d+) (?P<dev>\S+) (?P<inode>\S+)\s+(?P<path>\S+)')
with open("/proc/self/maps", 'r') as maps_fd, open("/proc/self/mem", 'rb', 0) as mem_fd:
    for line in maps_fd.readlines():
        m = r.match(line)
        if m and m.group('perm').startswith('r-'):  # if this is a readable ro region
            start = int(m.group('start'), 16)
            end = int(m.group('end'), 16)
            mem_fd.seek(start)  # seek to region start
            chunk = mem_fd.read(end - start)  # read region contents
            print(hashlib.sha256(chunk).hexdigest(), m.group('path'))

(для областей без <path> не считает, надо регексп допилить.

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

Я не полностью понял, что ты имеешь ввиду. Поясни, пожалуйста.

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

Короче говоря, я хотел сказать, что сравнивать чексумму в бинарнике и в памяти - не совсем правильно.

К сожалению, я слабо знаю структуру ELF-бинаря. То, что я писал выше, актуально для Mach-O. Тем паче, может быть, для линукса шифрование бинарника не актуально ;)

Я не полностью понял, что ты имеешь ввиду

У меня есть старенький ноут, на нём иногда чудеса происходят. Вот однажды skype выдал что он повреждён. Мне стало интересно как это он понял и можно ли в свою программу встроить такую проверку.

сравнивать чексумму в бинарнике и в памяти - не совсем правильно.

согласен, в общем случае может и не выйдет. Поэтому и спросил что за случаи.

Вот однажды skype выдал что он повреждён.

Это при запуске (ошибка на винчестере) или после некоторого времени выполнения (ошибка работы ОЗУ)?

или после некоторого времени выполнения (ошибка работы ОЗУ)?

Ошибка либо в оперативе, либо в кэшах проца (встречал такое в dmesg у себя на сервере). Судя по тому что drop_caches помог проблема была (и есть :)) в оперативе.