А положение шариков в пространстве - уже вполне физическая. И угол поворота стрелки прибора - тоже. Такой прибор будет показывать своей стрелкой меру свободы системы из N шариков, выложенных в ряд в коробке размером 1xN, которые мы можем переставлять.
Или весь смысл этой ветки сводится к обсуждению классического определения "измерительный прибор - средство измерений, предназначенное для получения значений измеряемой физической величины в установленном диапазоне"?
Шарики в коробке же.
Робот откроет коробку, попереставляет в ней шарики, а потом закроет её обратно.
ограничением будет время жизни вселенной примерно
Не надо засовывать в такой прибор коробки, в которых больше 10 шариков. Так же, как не надо вольтметром измерять те напряжения, от которых он сгорит, а на весы ставить грузы, для которых они не предназначены.
Пока не понимаю, почему не получается. Ящик, внутри робот с памятью, который двигает шарики и отклоняет стрелочку на +1 каждый раз, когда видит новую перестановку.
Как у любого измерительного прибора, у него будет ограничения на число шариков, обусловленные производительностью манипуляторов робота и объёмом его памяти.
Если ящик с прибором чёрный, то никто и не узнает, что прибор жульничает. :)
Но если хочется честно - поделить условной границей их на те, что манипулятор уже двигал, и те, что нет, а дальше рекурсивным алгоритмом двигая границу получить все перестановки - создавать такие конфигурации, которые прибор ещё не видел с момента начала измерения. Ведь мелкие шарики не будут абсолютно одинаковыми - у них отличается по крайней мере положение в пространстве, а значит прибор сможет их друг от друга отличать.
Набор манипуляторов, которые переставляют предметы и датчиков, которые позволяют отличить предметы от друга. Пытаемся изменить состояние предметов внутри прибора, прикидываем их число, повторяем процесс до сходимости их количества. Затем считаем факториал и выдаём результат наружу.
API OSS перестаёт быть удобным, когда нужно реализовывать не push (приложение заранее подготовило звук и делает write в сторону ядра), а pull (ядро понимает, что железу скоро будет нечего воспроизводить, и просит приложение сгенерировать новые аудиоданные).
Не очень понятно, почему иксовый сервер работать не будет, а OGLOED - будет. И если у нас уже есть мощная 16-ядерная машина для запуска приложения, а External Device маломощный и отгороженный проприетарной ОС, то почему бы просто не стримить уже готовое видео?
А зачем выпиливать механизм аттестации? Всё равно решение принимает вебмастер - доверять конкретному юзер-агенту или нет.
Чем больше будет браузеров, поддерживающих измерение платформы, на которых они исполняются, и чем больше будет измеряемых платформ, тем больше будет выбор у пользователя, которого ограничивает вебмастер требованием успешного прохождения аттестации.
Конечно же, мне не понравится то, что когда я зайду на сайт своего банка, он потребует от меня использовать определённый браузер. Но пусть лучше этих браузеров будет хотя бы два, а не один.
Можно попробовать реализовать такую схему с помощью TOFU, просто сильно расширив номерную ёмкость. Скажем, сделать номера мобильных телефонов не из трёхзначного кода оператора и семизначного номера абонента, а раздуть номер абонента до 38 цифр. А у абонента должна быть возможность генерировать себе новые номера.
Тогда схема для пользователя будет выглядеть так: "Вован, тут Вася тебя спрашивал, я скину ему номер?" — "Да, скинь ему +765412345678901234567890123456789012345678". При первом звонке Васи, телефон (или даже оператор) Вована запоминает пару номеров {from; to} и не принимает больше на свой номер звонки от других абонентов. Можно ещё дать возможность сбрасывать такой known_hosts или включать soft-fail режим.
Заодно и перебирать такую ёмкость спаммерам будет сильно сложнее.
Для ноутбука уже есть простой способ обезопасить свои данные - включить полнодисковое шифрование, которое предлагает разработчик вашей ОС. Этот способ легко применить даже неискушённому пользователю, и против нетаргетированного вора вполне работает.
То, что описываете вы уже больше похоже на стеганографию. Когда нужно не только сами данные защитить, но и скрыть (или сделать недоказуемым) сам факт их существования. Если у вас появилась необходимость решать такую задачу, значит простой способ "зашифровать всё" вам почему-то не подходит - наверное, и атакующий в таком случае будет покруче.
вы хотите чтобы я вам разработал систему с быстрым доступом, с мобильным приложением и с интеграцией во все ОС?
Нет, я лишь хочу понять общий принцип. Если я использую какие-то традиционные способы, типа архива с паролем, то декодировщик у меня уже есть в программе-архиваторе. А если я применяю какой-то необычный способ кодирования, то декодировщик нухно откуда-то принести. А сам факт наличия такого декодировщика поможет атакующему, особенно если вся защита строится на принципе "security through obscurity". Даже если он сам не справится, то знание того, что тут кто-то что-то скрывает будет мотивировать его нанять более опытного взломщика.
Вот я и пытаюсь понять, что вы предлагаете - как-то хитро скрыть декодировщик, или же каждый раз по памяти набирать код программы, не сохраняя её на диск?
вот попал вам в руки мой ноутбук, вы даже знать не будете где искать
Для каждого файла в System32 есть не так много источников, из которых он может там появиться. По системным журналам и реестру можно узнать, какая версия ОС устанавливалась, и какие сервиспаки на неё потом в каком порядке накатывались. Если wmms32.ocx ни в одном дистрибутиве не присутствует, то это явным образом указывает на то, что кто-то его туда руками подложил. Можно попробовать поискать в интернете хеш любого неизменённого системного файла из популярных ОС - почти наверняка он найдётся.
никто не знает чем и как закодировано
А как потом самому раскодировать? Каждый раз грузиться в live-систему и писать по-памяти программу-раскодировщик?
Можно пропустить данные через дельта-кодек, а потом сжать. А рядом положить файл "засечек", описывающий смещения в сжатых данных, чтобы быстро делать seek и разжимать только нужные блоки.
Если конвейер обработки данных фиксирован и заранее известен, то можно очень эффективно используя SIMD прогонять через него больше потоки. Если возможности зафиксировать его полностью нет - например, оператор в интерактивном режиме вводит аналитический запрос, то можно разбить его на стадии, а самые тугие циклы прогнать через JIT.
Сжатие данных экономит пропускную способность шин и позволяет записывать их в удобном человеку формате. Выигрыш в скорости часто оказывается больше, чем затраты ресурсов CPU на работу распаковщика.
Я именно про dns.he.net, а не про tunnelbroker.com - с последним, действительно, будут проблемы со связностью, приходится использовать других брокеров. Но cloudflared позволяет эти проблемы обойти по IPv4, даже если машина находится за NAT.
Cloudflare и dns.he.net всё ещё бесплатные. В первом случае можно даже ничего не делать с DDNS - достаточно либо IPv6 адреса на upstream-сервере, либо запущенного cloudflared для реверс-проксирования.
Если в образе лежит единственный статический бинарник (например, FROM scratch с программой на Go или Rust так часто докеризируют), то поставить туда curl может быть затруднительно. А так можно воспользоваться одноразовым контейнером, а после использования - удалить.
Для единообразия. Он может быть использован, например, в каком-нибудь сервисном образе (через FROM curlimages/curl), CMD которого ходит в соседний контейнер, чтобы создать системного пользователя через HTTP API.
Читая исходники оригинального Heretic при портировании, узнал интересное:
шары из зелени, которые вместо бочек из Doom, называются puff pod, а маленькие и большие пачки патронов – wimpy и hefty соответственно;
если активное оружие игрока - перчатки, то на него не действуют внешние силы, толкающие игрока (в терминах движка - не наращиваются моменты, momx/momy), похоже, что это хак, чтобы игрок притягивался к врагам во время атаки;
если упасть на монстра сверху, то игроку выставляется флаг, дающий ему пожизненный (но сбрасываемый при перезагрузке уровня) air control, позволяя лучше маневрировать;
в демках углы поворота мышью записаны с меньшим разрешением (один байт вместо двух), а родные демки от Raven Software в IWAD поломаны начиная с версии 1.3;
на поведение генератора случайных чисел влияет вообще всё, включая покачивание цепочки здоровья в статусбаре - при прохождении E1M1 игра потребляет сотни случайных чисел в секунду;
таблицы синуса/косинуса и тангенса содержат небольшие нарушения симметрии, и при попытке заменить их библиотечными вызовами демки тоже ломаются;
в Wolf3D используется другая формула для умножения fixed16.16-чисел: (a >> 8) * (b >> 8), а в Doom/Heretic: ((int64_t) a * (int64_t) b) >> 16, из-за чего получаются разные ошибки округления;
в коде перехода между уровнями есть ошибка, позволяющая игроку пронести крылья на следующий уровень, если они активны, а второй их экземпляр лежит в инвентаре, причём в функции G_PlayerFinishLevel есть вызов memset, который бы исправлял это, но он закомментирован.
А положение шариков в пространстве - уже вполне физическая. И угол поворота стрелки прибора - тоже. Такой прибор будет показывать своей стрелкой меру свободы системы из N шариков, выложенных в ряд в коробке размером 1xN, которые мы можем переставлять.
Или весь смысл этой ветки сводится к обсуждению классического определения "измерительный прибор - средство измерений, предназначенное для получения значений измеряемой физической величины в установленном диапазоне"?
Робот откроет коробку, попереставляет в ней шарики, а потом закроет её обратно.
Не надо засовывать в такой прибор коробки, в которых больше 10 шариков. Так же, как не надо вольтметром измерять те напряжения, от которых он сгорит, а на весы ставить грузы, для которых они не предназначены.
Пока не понимаю, почему не получается. Ящик, внутри робот с памятью, который двигает шарики и отклоняет стрелочку на +1 каждый раз, когда видит новую перестановку.
Как у любого измерительного прибора, у него будет ограничения на число шариков, обусловленные производительностью манипуляторов робота и объёмом его памяти.
Если ящик с прибором чёрный, то никто и не узнает, что прибор жульничает. :)
Но если хочется честно - поделить условной границей их на те, что манипулятор уже двигал, и те, что нет, а дальше рекурсивным алгоритмом двигая границу получить все перестановки - создавать такие конфигурации, которые прибор ещё не видел с момента начала измерения. Ведь мелкие шарики не будут абсолютно одинаковыми - у них отличается по крайней мере положение в пространстве, а значит прибор сможет их друг от друга отличать.
Набор манипуляторов, которые переставляют предметы и датчиков, которые позволяют отличить предметы от друга. Пытаемся изменить состояние предметов внутри прибора, прикидываем их число, повторяем процесс до сходимости их количества. Затем считаем факториал и выдаём результат наружу.
API OSS перестаёт быть удобным, когда нужно реализовывать не push (приложение заранее подготовило звук и делает write в сторону ядра), а pull (ядро понимает, что железу скоро будет нечего воспроизводить, и просит приложение сгенерировать новые аудиоданные).
Не очень понятно, почему иксовый сервер работать не будет, а OGLOED - будет. И если у нас уже есть мощная 16-ядерная машина для запуска приложения, а External Device маломощный и отгороженный проприетарной ОС, то почему бы просто не стримить уже готовое видео?
А зачем выпиливать механизм аттестации? Всё равно решение принимает вебмастер - доверять конкретному юзер-агенту или нет.
Чем больше будет браузеров, поддерживающих измерение платформы, на которых они исполняются, и чем больше будет измеряемых платформ, тем больше будет выбор у пользователя, которого ограничивает вебмастер требованием успешного прохождения аттестации.
Конечно же, мне не понравится то, что когда я зайду на сайт своего банка, он потребует от меня использовать определённый браузер. Но пусть лучше этих браузеров будет хотя бы два, а не один.
Можно попробовать реализовать такую схему с помощью TOFU, просто сильно расширив номерную ёмкость. Скажем, сделать номера мобильных телефонов не из трёхзначного кода оператора и семизначного номера абонента, а раздуть номер абонента до 38 цифр. А у абонента должна быть возможность генерировать себе новые номера.
Тогда схема для пользователя будет выглядеть так: "Вован, тут Вася тебя спрашивал, я скину ему номер?" — "Да, скинь ему +765412345678901234567890123456789012345678". При первом звонке Васи, телефон (или даже оператор) Вована запоминает пару номеров {from; to} и не принимает больше на свой номер звонки от других абонентов. Можно ещё дать возможность сбрасывать такой known_hosts или включать soft-fail режим.
Заодно и перебирать такую ёмкость спаммерам будет сильно сложнее.
Там несколько микросхем: QSPI флешка на 8МБ (кандидат №1 из статьи) с биосом и I²C EEPROM на 1КБ (кандидат №3) с паролем.
Для ноутбука уже есть простой способ обезопасить свои данные - включить полнодисковое шифрование, которое предлагает разработчик вашей ОС. Этот способ легко применить даже неискушённому пользователю, и против нетаргетированного вора вполне работает.
То, что описываете вы уже больше похоже на стеганографию. Когда нужно не только сами данные защитить, но и скрыть (или сделать недоказуемым) сам факт их существования. Если у вас появилась необходимость решать такую задачу, значит простой способ "зашифровать всё" вам почему-то не подходит - наверное, и атакующий в таком случае будет покруче.
Нет, я лишь хочу понять общий принцип. Если я использую какие-то традиционные способы, типа архива с паролем, то декодировщик у меня уже есть в программе-архиваторе. А если я применяю какой-то необычный способ кодирования, то декодировщик нухно откуда-то принести. А сам факт наличия такого декодировщика поможет атакующему, особенно если вся защита строится на принципе "security through obscurity". Даже если он сам не справится, то знание того, что тут кто-то что-то скрывает будет мотивировать его нанять более опытного взломщика.
Вот я и пытаюсь понять, что вы предлагаете - как-то хитро скрыть декодировщик, или же каждый раз по памяти набирать код программы, не сохраняя её на диск?
Для каждого файла в System32 есть не так много источников, из которых он может там появиться. По системным журналам и реестру можно узнать, какая версия ОС устанавливалась, и какие сервиспаки на неё потом в каком порядке накатывались. Если wmms32.ocx ни в одном дистрибутиве не присутствует, то это явным образом указывает на то, что кто-то его туда руками подложил. Можно попробовать поискать в интернете хеш любого неизменённого системного файла из популярных ОС - почти наверняка он найдётся.
А как потом самому раскодировать? Каждый раз грузиться в live-систему и писать по-памяти программу-раскодировщик?
Сработало на Яндекс Телефоне с LineageOS.
Можно пропустить данные через дельта-кодек, а потом сжать. А рядом положить файл "засечек", описывающий смещения в сжатых данных, чтобы быстро делать seek и разжимать только нужные блоки.
Если конвейер обработки данных фиксирован и заранее известен, то можно очень эффективно используя SIMD прогонять через него больше потоки. Если возможности зафиксировать его полностью нет - например, оператор в интерактивном режиме вводит аналитический запрос, то можно разбить его на стадии, а самые тугие циклы прогнать через JIT.
Сжатие данных экономит пропускную способность шин и позволяет записывать их в удобном человеку формате. Выигрыш в скорости часто оказывается больше, чем затраты ресурсов CPU на работу распаковщика.
Я именно про dns.he.net, а не про tunnelbroker.com - с последним, действительно, будут проблемы со связностью, приходится использовать других брокеров. Но cloudflared позволяет эти проблемы обойти по IPv4, даже если машина находится за NAT.
Cloudflare и dns.he.net всё ещё бесплатные. В первом случае можно даже ничего не делать с DDNS - достаточно либо IPv6 адреса на upstream-сервере, либо запущенного cloudflared для реверс-проксирования.
Если в образе лежит единственный статический бинарник (например, FROM scratch с программой на Go или Rust так часто докеризируют), то поставить туда curl может быть затруднительно. А так можно воспользоваться одноразовым контейнером, а после использования - удалить.
Для единообразия. Он может быть использован, например, в каком-нибудь сервисном образе (через FROM curlimages/curl), CMD которого ходит в соседний контейнер, чтобы создать системного пользователя через HTTP API.
Читая исходники оригинального Heretic при портировании, узнал интересное:
шары из зелени, которые вместо бочек из Doom, называются puff pod, а маленькие и большие пачки патронов – wimpy и hefty соответственно;
если активное оружие игрока - перчатки, то на него не действуют внешние силы, толкающие игрока (в терминах движка - не наращиваются моменты, momx/momy), похоже, что это хак, чтобы игрок притягивался к врагам во время атаки;
если упасть на монстра сверху, то игроку выставляется флаг, дающий ему пожизненный (но сбрасываемый при перезагрузке уровня) air control, позволяя лучше маневрировать;
в демках углы поворота мышью записаны с меньшим разрешением (один байт вместо двух), а родные демки от Raven Software в IWAD поломаны начиная с версии 1.3;
на поведение генератора случайных чисел влияет вообще всё, включая покачивание цепочки здоровья в статусбаре - при прохождении E1M1 игра потребляет сотни случайных чисел в секунду;
таблицы синуса/косинуса и тангенса содержат небольшие нарушения симметрии, и при попытке заменить их библиотечными вызовами демки тоже ломаются;
в Wolf3D используется другая формула для умножения fixed16.16-чисел: (a >> 8) * (b >> 8), а в Doom/Heretic: ((int64_t) a * (int64_t) b) >> 16, из-за чего получаются разные ошибки округления;
в коде перехода между уровнями есть ошибка, позволяющая игроку пронести крылья на следующий уровень, если они активны, а второй их экземпляр лежит в инвентаре, причём в функции G_PlayerFinishLevel есть вызов memset, который бы исправлял это, но он закомментирован.
А спать на диванах в кабинетах-переговорках начальников.
Ирландия, банкоматы EuroNet.