На начальном этапе взлома на устройство жертвы через iMessage поступало сообщение с вредоносными данными, эксплуатирующими уязвимость CVE-2023-41990 в реализации Apple обработки шрифтов TrueType. Данная уязвимость позволяла удалённо выполнять код с минимальными привилегиями и переходить к следующему этапу, целью которого был доступ к ядру iOS.
Мысль вслух. Интерпретатор всем известных TrueType шрифтов (TTF) является forth-подобной виртуальной машиной. Что если использовать её как "weird machine" ? Жертве остается только открыть PDF со вложенным "шрифтом".
Теперь к printf. У неё есть малоизвестный спецификатор %n. Все остальные — %d, %s и прочие — читают данные из аргументов и выводят на экран. %n делает обратное: берёт адрес из аргумента и записывает туда число символов, которые printf уже вывела к этому моменту. Да, функция вывода текста умеет писать в произвольную память.
"Век живи, век учись, - подумал поручик и переложил серебрянный портсигар из кармана штанов в нагрудный карман." (с) ...
Недавно приобрел подобную машинку, только называется TECNO MEGA MINI ML01 и внутри AMD Ryzen 5 7535H с 16ГБ DDR5. Тест производительности выдает 255000 очков по CoreMark MT. Разобрался как на ней включить UART и нашел его на материнке. Теперь можно дебажить ядро FreeBSD по полной. :-)
root@megamini:/home/rz/coremark # ./coremark-amd64-12p.exe
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 18782
Total time (secs): 18.782000
Iterations/Sec : 255563.837717
Iterations : 4800000
Compiler version : GCCFreeBSD Clang 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Compiler flags : -O2 -DMULTITHREAD=12 -DUSE_FORK -DPERFORMANCE_RUN=1 -lrt
Parallel Fork : 12
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 255563.837717 / GCCFreeBSD Clang 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) -O2 -DMULTITHREAD=12 -DUSE_FORK -DPERFORMANCE_RUN=1 -lrt / Heap / 12:Fork
CPU-X
Всё таки "красненькие" ныньче уделывают "голубых". :)
В FTN было все просто - канал всегда существует только между двумя точками и этот канал не мешает работе остальным участникам сети. Канал достаточно быстрый и надежный.
Для реализации Вашей идеи потребуется изобрести очень сложный протокол типа Point-to-Multipoint с ретранзмитами. По верх него выстроить какую-то сетевую административную структуру также работающую по принципу P2M. В общем, тут исследовательской работы на годы вперед. :)
Но самое фиговое то, что скорость у LoRa катастрофически низка - это считаные байты в секунду!!! Размер пакета в 240 байт создаст огромный процент служебного трафика (overhead). Вобщем, передавать по LoRa что-либо отличное от классических телеграмм SMS не получится!
У меня на фидошном узле, под его закат, дневной трафик составлял под сотню мегабайт. Mesh-сети на базе LoRa даже близко не соответствуют тому, что было (могло) Fidonet и FTN.
MeshCore в его нынешнем виде больше похож на пакетную радиолюбительскую F6BB BBS из середины 90-х. В целом это тоже было в ходу, но требовало громоздкого оборудования, некого обьема знаний и массу везения. :-)
Подскажите, для LilyGo T-LoRa V2.1-1.6 прошивка под MeshCore есть в природе ?
PS: Попробовла Meshtastic - полная лажа, уж извините. Нахожусь в центре города на 10м этаже с выносной вертикальной антенной, нод слышу - горы, но вероятность доставки пакета до узла назначения близка к нулю. То проходит, то не проходит, достижимость то появится, то исчезнет (ноды в постоянном движении). Когда требуется действительно что-то передать (ну там в кабак другана позвать) - недокричишься. :-)
"Тратить" - это всегда бесполезно и бездарно, а вот "потреблять" - всегда с пользой. Так, что всё верно написано - Гугл бездарно тратит дорогостоящую электроэнергию. :)
Я вижу, что Вы совсем ничего не знаете о базах данных и о их бэкапе - видимо недостаточно печального опыта еще накопили.
Чтобы сделать бэкап СУБД её требуется остановить, иначе имеется немалый шанс нарушить целостность хранящихся в ней данных. Процедура бэкапа по Вашей схеме занимает достаточно приличное время, всё это вемя база будет недоступна, запросы в неё требуется переадресовывать в другую (вспомогатальную) базу. По окончаю бэкапа, данные из вспомогательной базы требуется перенести обратно в основную не нарушив целостности (синхронизация - это нихрена не просто). Короче, #бли в этой классической схеме просто предостаточно, и в конечном счете, ровно в час "Ы" окажется, что бэкап не работает или сломан.
C ZFS снимок делает почти мгновенно - база останавливается на считанные секунды, делается снимок и база запускается обратно в работу. Далее со снимком можете делать что угодно, копировать его куда угодно, сколько бы времени это не заняло.
Про восстановление базы данных из бэкапа в классическом варианте писать не буду - эта проблема вообще очень сложна и многогранна для такого поста. Но ZFS значительно упрощает решение и этой задачи.
Молодец! Выявить и исправить баг с софте - дело благородное и общественно полезное. Осталось запушить патч в апстрим и не умереть при этом от потока кала в свой адрес.
Как-то давно вычитал, что так как у Марса остывшее ядро, то у него 1) нет своего магнитного поля для защиты от солнечной радиации, 2) не может быть своей плотной атмосферы подобной земной. Оба фактора ставят крест на всех потугах колонизации и терроформирования. Нет ни малейшего смысла человеку переселяться на мёртвую планету.
За малым нюансом: вместо ACPI для конфигурации и управления настройками аппаратуры используется Flattened Device-Tree файл (DTB файл), а вся эта кухня представляет собой отдельный дивный мир со своими чудесами. :-)
Ну как по мне, лучше уж U-Boot + Device-Tree, чем UEFI + ACPI.
KASRL и ASLR это разные вещи!!! ASLR - это User-space address randomization. Поддержка ASRL есть во всех BSD. В OpenBSD есть KARL - это свой вариант KASLR, не знаю включен он или нет по умолчанию. Во FreeBSD есть только ASRL и он включен по умолчанию для 64-х битный приложений, но этого явно недостаточно когда мы говорим о багах в ядре ОС.
Опять я опоздал с идеей. :-)
Мысль вслух. Интерпретатор всем известных TrueType шрифтов (TTF) является forth-подобной виртуальной машиной. Что если использовать её как "weird machine" ? Жертве остается только открыть PDF со вложенным "шрифтом".
"Век живи, век учись, - подумал поручик и переложил серебрянный портсигар из кармана штанов в нагрудный карман." (с) ...
Хорошая статья, спасибо. Правда аудитория здесь непригодная для таких тем, IMHO.
Недавно приобрел подобную машинку, только называется TECNO MEGA MINI ML01 и внутри AMD Ryzen 5 7535H с 16ГБ DDR5. Тест производительности выдает 255000 очков по CoreMark MT. Разобрался как на ней включить UART и нашел его на материнке. Теперь можно дебажить ядро FreeBSD по полной. :-)
CPU-X
Всё таки "красненькие" ныньче уделывают "голубых". :)
Дык ить! Наш
паровозкомплект FTN всегда стоит на запасном пути. ;)PS: Вангую, что с таким хаосом что сейчас происходи в мире, должна в скорости появиться независимая (от существующей) сеть DNS серверов.
Вы еще предложите настраивать NIS/YP.
В FTN было все просто - канал всегда существует только между двумя точками и этот канал не мешает работе остальным участникам сети. Канал достаточно быстрый и надежный.
Для реализации Вашей идеи потребуется изобрести очень сложный протокол типа Point-to-Multipoint с ретранзмитами. По верх него выстроить какую-то сетевую административную структуру также работающую по принципу P2M. В общем, тут исследовательской работы на годы вперед. :)
Но самое фиговое то, что скорость у LoRa катастрофически низка - это считаные байты в секунду!!! Размер пакета в 240 байт создаст огромный процент служебного трафика (overhead). Вобщем, передавать по LoRa что-либо отличное от классических
телеграммSMS не получится!10 лет назад типовой малобюджетный рутер имел минимум 2ГБ памяти, то есть в 1024 раза больше.
У меня на фидошном узле, под его закат, дневной трафик составлял под сотню мегабайт. Mesh-сети на базе LoRa даже близко не соответствуют тому, что было (могло) Fidonet и FTN.
MeshCore в его нынешнем виде больше похож на пакетную радиолюбительскую F6BB BBS из середины 90-х. В целом это тоже было в ходу, но требовало громоздкого оборудования, некого обьема знаний и массу везения. :-)
Скорее всего ничего не случится, на такой высоте подьема дальность растространения сигнала будет небольшой - cлегка загадят эфир в своем дворе.
Подскажите, для LilyGo T-LoRa V2.1-1.6 прошивка под MeshCore есть в природе ?
PS: Попробовла Meshtastic - полная лажа, уж извините. Нахожусь в центре города на 10м этаже с выносной вертикальной антенной, нод слышу - горы, но вероятность доставки пакета до узла назначения близка к нулю. То проходит, то не проходит, достижимость то появится, то исчезнет (ноды в постоянном движении). Когда требуется действительно что-то передать (ну там в кабак другана позвать) - недокричишься. :-)
"Продуктами" называть то, что сейчас продается в магазинах - язык не поворачивается. А питаемся, в основном, тем, что вырастили на даче.
Очевидно же, что в магазине продают всякий junk.
"Тратить" - это всегда бесполезно и бездарно, а вот "потреблять" - всегда с пользой. Так, что всё верно написано - Гугл бездарно тратит дорогостоящую электроэнергию. :)
Я вижу, что Вы совсем ничего не знаете о базах данных и о их бэкапе - видимо недостаточно печального опыта еще накопили.
Чтобы сделать бэкап СУБД её требуется остановить, иначе имеется немалый шанс нарушить целостность хранящихся в ней данных. Процедура бэкапа по Вашей схеме занимает достаточно приличное время, всё это вемя база будет недоступна, запросы в неё требуется переадресовывать в другую (вспомогатальную) базу. По окончаю бэкапа, данные из вспомогательной базы требуется перенести обратно в основную не нарушив целостности (синхронизация - это нихрена не просто). Короче, #бли в этой классической схеме просто предостаточно, и в конечном счете, ровно в час "Ы" окажется, что бэкап не работает или сломан.
C ZFS снимок делает почти мгновенно - база останавливается на считанные секунды, делается снимок и база запускается обратно в работу. Далее со снимком можете делать что угодно, копировать его куда угодно, сколько бы времени это не заняло.
Про восстановление базы данных из бэкапа в классическом варианте писать не буду - эта проблема вообще очень сложна и многогранна для такого поста. Но ZFS значительно упрощает решение и этой задачи.
Молодец! Выявить и исправить баг с софте - дело благородное и общественно полезное. Осталось запушить патч в апстрим и не умереть при этом от потока кала в свой адрес.
Как-то давно вычитал, что так как у Марса остывшее ядро, то у него 1) нет своего магнитного поля для защиты от солнечной радиации, 2) не может быть своей плотной атмосферы подобной земной. Оба фактора ставят крест на всех потугах колонизации и терроформирования. Нет ни малейшего смысла человеку переселяться на мёртвую планету.
За малым нюансом: вместо ACPI для конфигурации и управления настройками аппаратуры используется Flattened Device-Tree файл (DTB файл), а вся эта кухня представляет собой отдельный дивный мир со своими чудесами. :-)
Ну как по мне, лучше уж U-Boot + Device-Tree, чем UEFI + ACPI.
KASRL и ASLR это разные вещи!!! ASLR - это User-space address randomization. Поддержка ASRL есть во всех BSD. В OpenBSD есть KARL - это свой вариант KASLR, не знаю включен он или нет по умолчанию. Во FreeBSD есть только ASRL и он включен по умолчанию для 64-х битный приложений, но этого явно недостаточно когда мы говорим о багах в ядре ОС.