Chebuya

Справедливости ради, модуль chacha20 и pbkdf2 писал не я ¯\_(ツ)_/¯ хз, есть поддержка монохромных мониторов, но на запуск проги надо оперативную память 1.5 уровня. максимальный размер файла неизвестен, но на потребление озу влияет только запись перед файлом, то есть: открываем файл в режиме append, и выполняем seek, допустим, на 0. Тогда весь файл будет записан в озу, что поделать ¯\_(ツ)_/¯

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

Представляю вам программу для (тавтология) полнодискового шифрования. Позволяет зашифровывать данные "на лету", в прозрачном режиме. Установка: Для OpenOS: wget -f https://raw.githubusercontent.com/BrightYC/Catch/main/catch.lua /bin/catch.lua Для MineOS же есть приложение в местном AppMarket, под названием Catch. Код обитает здесь: https://github.com/BrightYC/Catch/ Использование: В OpenOS, вы можете зашифровать любые диски, например, чтобы они были портативными Примеры: catch --encrypt --drive=XXX (Диск XXX будет зашифрован) catch --encrypt (Будет зашифрован относительный путь: например, если мы находимся в директории /mnt/xxx, диск xxx будет зашифрован, если мы находимся в главной директории - загрузочный диск будет зашифрован) catch --decrypt --drive=XXX (Диск XXX будет расшифрован) В MineOS, вы можете только зашифровать загрузочный диск, если же вы попытаетесь открыть программу на другому диске, программа запросит пароль для диска и смонтирует его по пути /Mounts/Catch-XXX. Если же запустить программу на другом диске с аргументом rootfs, будет запущена программа для шифрования, как обычно. Количество итераций: Количество итераций определяет сложность вычисления ключа, чем выше количество - тем сложнее взломать ключ. Если количество итераций слишком высокое - расшифровка диска будет выполняться очень медленно, цифра в 1-2 минуты вполне реальна. Стандартное значение - 5000. Количество итераций можно указать только в OpenOS. Пример: catch --encrypt --iter-time=3000 Программа в MineOS: Видеодемонстрация:

восстановили.

Кому все еще нужно, в местном магазине теперь есть приложение OpenOS Имеется интеграция с майносью, а именно: Отображение os.getenv('_') в титлбаре Настоящий биос доступен из опеноси непосредственно computer.addUser/computer.removeUser/computer.uptime работают с настоящим компьютером Цветовая схема Настоящий диск смонтирован по пути /mnt/mineos

Неделю назад доделал одну вещь, что-то вроде VeraCrypt. Что стоит отметить: OC слишком тормознутый, чтобы какие-либо KDF работали достаточно быстро (100 тысяч итераций выполнится за полторы минуты, но 1000 итераций выполняется достаточно шустро). Потребление озу в той же MineOS легко доходит до 90%, если, например, открыть какой-нибудь жирный файл.

table.sort(table, function(a, b) return a < b end) в обратном порядке: table.sort(table, function(a, b) return a > b end)

со стороны взломщиков появилась идея. Хранить код для пробуждения на сервере, а для самого модема выставить сигнал на пробуждение. Перед выполнением любого кода отсылать на сервер, что робот выполняет код - и начинает в цикле while true do end посылать сигнал на wakeup.

проверил, оказывается, даже если код обвернут в pcall, tlwy вылетает сразу, провоцируя выключение компьютера.

но каким образом это поможет если, сам этот код обвернут в pcall? local chunkFromServer = [[ while true do pcall(function() for i=1,1e15 do end end) end ]] local chunk = load(chunkFromServer) if chunk then pcall(chunk) end

https://github.com/Shuudoushi/SecureOS из мода OC давно удалена (по крайней мере на 1.12)

Нельзя. Программа на уровне EEPROM может подменить вызовы и к component.invoke. В том числе и к очереди сигналов и прокси компонентов.

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

какой смысл, если EEPROM могли подменить? Ну засунешь дискету - а какой смысл, если код был запущен еепромой, которая пожет подменить *все*. Кстати, немного оффтопа, но дата-карта не обязательна. Она медленнее, чем software решения.

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

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

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

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

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

Но как поступать, если в дрона/робота вставили интернет-карту? в таком случае можно забивать робота мусорными компонентами для увеличения сложности? (как можно определить уровень процессора внутри окружения? мне кажется, это возможно)

Но как понять, когда предел, если сам компьютер, собственно, был подменен? при сборке дрона/робота ставить максимальное количество плашек? Если с дроном еще более-менее прозрачно, то что делать с роботом, если туда могли всунуть дополнительный диск для хранения данных уже непосредственно в ПЗУ?

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

хорошо, я не вижу подвоха здесь пока что, но как поступать, если злоумышленник будет хранить данные в tmpfs? она не чистится, если был soft reboot. или в конце концов интернет-карта или беспроводная карта.

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

Мне показалось, что защищающаяся сторона должна хранить где-то код. Но даже так взломщик может тоже хранить оригинальный код у себя на сервере. Проблема вот в чем: злоумышленник может просто взять оригинальный код еепромы, сделать что-то вроде: data = maliciousChunk .. eeprom.get() и потом если проверяющая сторона запрашивает код, мы просто делаем что-то вроде этого: modem.send(serverAddress, eeprom.get():sub(maliciousChunk, #eeprom.get()) P.S Или даже проще, банально разделив полезную нагрузку и потом вычленив gsub'ом modem.send(.., eeprom.get:gsub("|(.+)"))