eu_tomat

Что-то лагерь взломщиков долго молчит.

Поясню свой предыдущий ответ:

В 07.05.2021 в 15:28, eu_tomat сказал:

Разумеется, код обёрнут в pcall. И упадёт он независимо от лагов. Заворачиваем цикл в pcall и выполняем. А потом ещё раз выполняем. И ещё.

Код может выглядеть, например, так:

while true do
  pcall(function()
    for i=1,1e15 do end
  end)
end

Это код должен спровоцировать ошибку TLWY и отключение робота.

37 минут назад, Taruu сказал:

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

Анализатор в любом случае выдаст правильный результат.

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

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

23 минуты назад, BrightYC сказал:

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

Разумеется, код обёрнут в pcall. И упадёт он независимо от лагов. Заворачиваем цикл в pcall и выполняем. А потом ещё раз выполняем. И ещё.

25 минут назад, ProgramCrafter сказал:

Теперь у злоумышленников вместо робота стоит компьютер с интернет-картой

Уже обсуждали выше. Интернет-карта вносит задержку в ответы подозреваемого. Это слишком заметно.

3 минуты назад, BrightYC сказал:

Подменить computer.shutdown на свой код, который просто будет отсчитывать время, когда нужно ответить в следующий раз.

Соглсен. На computer.shutdown полагаться нельзя. Останов по TLWY будет понадёжнее.

Только что, ProgramCrafter сказал:

Теперь к сообщению для пробуждения можно добавить код исходного EEPROM и отрезать его при запросе. При этом робот лишается возможности загрузки по сети, но успешно представляется своим.

Логично. Но сервер может специально проверить, способен ли робот пробуждаться по сообщению, специально остановив его.

14 минуты назад, BrightYC сказал:

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

Ничто не мгновенно. Если нет лагов, то на сервере вся операция запроса и получения ответа длится 3 тика. Ещё 1 тик будет потрачен на чтение из EEPROM. Если испытуемому будет подсказывать сервер, хранящий оригинальный код в оперативной памяти, на операцию будет затрчено 6 тиков вместо ожидаемых 4. Да, разницу в два тика можно списать на лаги, но никто не мешает повторить запрос несколько раз, попутно контролируя наличие лагов на эталонном компьютере.

52 минуты назад, ProgramCrafter сказал:

данные можно хранить в сообщении для пробуждения у модема/связанной карты. Их тоже надо забивать псевдослучайными данными?

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

Не ясно, как будить такую плату, т.к. размер передаваемого сообщения ограничен 8 KiB. Можно, наверное, впихнуть дополнительную плату исключительно как носитель информации.

Но вернусь к теме.

Исходя из новейших данных, WakeMessage сетевой платы должен быть заполнен трудносжимаемыми данными размером 8 KiB. Можно было бы использовать и больший размер, но как тогда будить уснувших роботов? В этом решении я вижу уязвимость, но она, возможно, не единственная, поэтому я подожду ответного хода лагеря взломщиков.

15 минут назад, BrightYC сказал:

впрочем, у интернет карты ограниченная скорость ( 40 киб/с), думаю, это можно обыграть.

Да. Сетевые и связанные платы также вносят задержку. Какие ещё инструменты остались в распоряжении взломщика?

1 час назад, BrightYC сказал:

Но как понять, когда предел, если сам компьютер, собственно, был подменен? при сборке дрона/робота ставить максимальное количество плашек?

Да. Если секретность до сих пор оправдана, память не жалеем.

2 часа назад, BrightYC сказал:

что делать с роботом, если туда могли всунуть дополнительный диск для хранения данных уже непосредственно в ПЗУ?

А это как раз та самая дыра, про которую я упоминал ранее. Несколько лет назад я рассматривал только замену EEPROM в роботе, но не рассматривал возможности апргейда робота.

Но теперь я готов пойти ещё дальше. Цель оправдывает средства.

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

2 минуты назад, BrightYC сказал:

мы можем проксировать tmpfs и хранить файл который запросил сервер в озу, а настоящую еепрому хранить в tmpfs? и не допускать доступа к реальной tmpfs.

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

Даём испытуемому задачу заполнить псевдослучайными данными массив близкого к предельному размера, провести с этими данными псевдослучайные манипуляции и сообщить серверу сравнительно короткий ответ. В общем, всё то же самое, что и с tmpfs. Если испытуемый не смог дать ответ, значит отключился в беспамятстве, всё с ним понятно.

2 минуты назад, BrightYC сказал:

как поступать, если злоумышленник будет хранить данные в tmpfs?

Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу.

10 минут назад, BrightYC сказал:

насколько трудносжимаемым?

Например:

$ (dd if=/dev/urandom bs=4096 count=1 | gzip | dd > /dev/zero ) 2>&1 | grep bytes
4096 bytes (4,1 kB, 4,0 KiB) copied, 5,6993e-05 s, 71,9 MB/s
4119 bytes (4,1 kB, 4,0 KiB) copied, 4,2526e-05 s, 96,9 MB/s

Так... я обнаружил новую дыру в защите, но до неё мы еще не дошли. Поэтому продолжаем. Может, ещё что-то интересное обнаружится.

7 часов назад, BrightYC сказал:

data = maliciousChunk .. eeprom.get()

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

1 минуту назад, BrightYC сказал:

На зашифрованном сервере, который предварительно мы загрузили безопасно с трюком выше.

Тут я не понял. Ты сейчас за какую сторону выступаешь?

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

Ты парировал тем, что взломщик может отправить наш оригинальный код.

Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера.

Или взломщик также хранит наш оригинальный код уже на своём сервере? Я правильно понял?

6 минут назад, BrightYC сказал:

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

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

2 минуты назад, BrightYC сказал:

это не имеет смысла, т.к взломщик может просто отправить оригинальный код

Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты?

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

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

@LeshaInc, о чём так загрустил, что отметился под каждым постом этой темы?

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

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

Определить же факт модификации EEPROM не всегда возможно. Возможно, я не прав, но мне кажется, полностью публичное существование такой системы невозможно. Да, на начальном этапе можно и нужно вести публичное обсуждение. Но в конечном итоге каждая система должна будет заиметь свои уникальные секретные особенности, неожиданные для взломщика. Мотивированный взломщик может обойти каждый конкретный известный ему вариант, но вряд ли сможет написать универсальный анализатор кода.

Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи.

Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик?

1 минуту назад, BrightYC сказал:

Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника

Если злоумышленник перехватил все вызовы к периферии, уже ничто не будет секретным. Поэтому секретность уходит на второй план. А на первый выходит определение факта взлома.

4 минуты назад, Mihis сказал:

Думаю можно постоянно чекать чексум EEPROM.

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

@Mihis А можешь показать свинокрушение при загрузке новых чанков? Я никогда не сталкивался с таким явлением.

Я нашёл чуть более производительный вариант схемы реактора:

Алгоритм поиска оптимальной схемы я описал ранее: это заполнение плоскости "крестиком", перебор возможных вариантов сдвига и отбрасывание симметричных вариантов. Затем во всех вариантах я заполнял оставшиеся свободными слоты какими-то полезными компонентами и выбирал наиболее производительный вариант. В итоге я получил схему с производительностью 4280 eu/t.

@whiskas поступил чуть умнее. Взяв за основу симметричный моему сдвиг сетки, он немного сместил некоторые компоненты в уже занятых слотах, благодаря чему улучшил производительность реакторной схемы до 4340 eu/t.

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

В результате я смог немного увеличить производительность: до 4360 eu/t на уране и до 21798 eu/t на MOX-топливе. Дополнительным бонусом схемы стало отсутствие в ней отражателей, теперь используются лишь два типа компонентов. А перфекционистов может порадовать центральная симметрия схемы.

10 минут назад, AlexCatze сказал:

В теории, если точка посадки будет выше точки взлёта, и дрон не будет подниматься на высоту больше, чем точка посадки +4 блока, свинка не должна получить урон.

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

1 минуту назад, BrightYC сказал:

TLWY может вылетать просто так, если сервер очень сильно тормозит

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

49 минут назад, BrightYC сказал:

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

В этом звёзды сходятся довольно часто. Если на лагающем сервере скрипт while true do end завершается по TLWY, то pcall не гарантирует устойчивости.

3 минуты назад, BrightYC сказал:

С таким же успехом можно запустить while true do end и говорить "а у меня комп сломался!!!".

Потому-то и не запускаем. Как и скрипты в браузере.

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

20 минут назад, BrightYC сказал:

сделать внутри песочницы свой TLWY, блокирующие вызовы - подменить, стандартный while true do end отлавливается pcall'ом.

А каким образом внутри пользовательского кода OpenComputers можно реализовать механику TLWY? Насколько я понимаю, в лучшем случае можно убить скрипт по исчерпании доступного ему  времени, заданного в конфигурации мода или перехватить совершаемые им вызовы. А в худшем случае лагающий сервер выключит комп раньше. А ещё можно получить бан от админа.

И кроме стандартного while true do end можно придумать много других скриптов с тем же эффектом. Как предлагаешь бороться с ними?