eu_tomat

По указанной ссылке:

Должен сработать такой код: for idx, tbl in ipairs(items_data) do table.sort( tbl, function(a,b)return a[1]<b[1]end ) end

@chapo Если назвать таблицу именем table, то её имя перекроет доступ к стандартному объекту с именем table и не позволит воспользоваться его методом sort для сортировки таблицы. Поэтому, во-первых, предлагаю для начала дать таблице другое имя. Во-вторых, в исходном примере используется вложенная таблица. Это ошибка, или так было задумано? Предположу, что это ошибка. Тогда правильный пример будет выглядеть таким образом: local tbl = {'b', 'd', 'z', 'c', 'a'} table.sort( tbl ) for i=1,#tbl do print( i, tbl[i] ) end --[[ 1 a 2 b 3 c 4 d 5 z ]]

Несколько путаное изложение идеи, и я попробую расшифровать её для читателей, которые не в теме. Взломщик подменяет сообщение пробуждения модема своим. И с помощью дополнительного компьютера непрерывно будит робота по этому сообщению. При этом размер сообщения ограничен 8192 байт. И сервер защиты будет пытаться убедиться в том, что испытуемый робот пробуждается именно по оригинальному сообщению. Так как взломщик непрерывно будит робота другим сообщением, то сторона защиты не будет уверена, каким именно сообщением разбужен робот. На первый взгляд информации недостаточно, но её можно попытаться получить. Существуют тайминги на отключение по TLWY. Бесконечный цикл погасит компьютер через 110 тиков. По истечении этого времени сервер защиты должен послать сигнал пробуждения. Далее 2 тика будет затрачено на пробуждение робота. И первым делом по пробуждении он должен будет отослать на сервер защиты информацию о своём пробуждении. Для простоты робот будет отправлять ту самую строку, которая добивает размер EEPROM до 4096 байт. Чтобы зря не потреблять оперативную память, эту строку можно будет позже удалить (из оперативной памяти). Вторым сообщением робот должен будет отправить содержимое wakeMessage сетевой карты. Он потратит на это ещё два тика времени. Если код взломщика попытается отправить какую-либо информацию на свой сервер после получения кода с сервера защиты, он сдвинет время отсылки роботом сообщения о своём пробуждении на один тик независимо от используемой механики пробуждения. Возникшая задержка свидетельствует о наличии несанкционированного кода. Задержка может свидетельствовать и о лагах сервера. Но лучше перестраховаться и повторить попытку чуть позже, пока испытуемый не впишется в ожидаемую задержку. Обеспечит ли взломщик нужную задержку, или найдёт другую уязвимость в этой защите?

Что-то лагерь взломщиков долго молчит. Поясню свой предыдущий ответ: Код может выглядеть, например, так: while true do pcall(function() for i=1,1e15 do end end) end Это код должен спровоцировать ошибку TLWY и отключение робота.

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

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

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

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

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

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

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

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

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

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

Например: $ (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

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

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

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

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

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

Я когда-то давно пытался исследовать этот вопрос, но абсолютно непробиваемой и при этом удобной защиты у меня не получилось. Есть неудобный, но надёжный параноидальный вариант: не хранить ничего ценного в постоянной памяти робота, а любого перезагруженного робота считать скомпрометированным. Скомпрометированных роботов следует выводить на нейтральную территорию и проверять содержимое EEPROM аппаратным способом. А при обнаружении опасных изменений следует поменять открытые порты во всей системе, а сетевые карты как робота, так и общавшегося с ним планшета разобрать на запчасти. Определить же факт модификации EEPROM не всегда возможно. Возможно, я не прав, но мне кажется, полностью публичное существование такой системы невозможно. Да, на начальном этапе можно и нужно вести публичное обсуждение. Но в конечном итоге каждая система должна будет заиметь свои уникальные секретные особенности, неожиданные для взломщика. Мотивированный взломщик может обойти каждый конкретный известный ему вариант, но вряд ли сможет написать универсальный анализатор кода. Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи. Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик?

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

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

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