Хорошая интерпретация “чёрного ящика”, имхо — не такой-то он и чёрный, и совсем не глупый (“ахаха, ИИ просто предсказывает следующий токен”).
На ум приходит ещё такая аналогия: если у XOR Problem есть вполне строгое решение на трёх нейронах, причём это решение находится обычным обучением нейросети обратным распространением ошибки, то почему бы не предположить, что (хотя бы) формальная логика не может быть с высокой точностью свёрнута и запечена в достаточно большую нейросеть? Между задачей “возьми со входов числа A и B и выдай на выходе A xor B” и задачей “возьми со входа формальное описание аксиоматики и теорему и выдай на выходе формальное доказательство этой теоремы” не такая и большая разница с точки зрения формализации.
Хм, точно: если подвесить заряд над кольцом и подогнать массу, то это равносильно тому, что мы поместим невесомый заряд в центр кольца. И да, убежит он вверх или вниз, но прижимаясь к оси. Посыпаю голову точечными зарядами :)
Согласен. Но... меня терзают смутные сомнения, так как условия задачи уже не совсем в области определения теоремы Ирншоу: сама "твёрдая подпорка" уже невозможна в голой электростатике, так как внутри у неё всякая ковалентная и квантовая магия, чтобы существовал твёрдый материал, на который мы уже можем клеить магниты.
Если картинка не обманывает, то есть эквипотенциальные поверхности, которые в 3D выглядят как "эритроциты" (таблетки с вмятиной), что явно говорит о потенциальной яме: градиент поля (следовательно, сила) в такой вмятине будет смещать пробный заряд ближе к оси... и нам осталось навесить сверху гравитацию, чтобы такой заряд не улетал от кольца, а возвращался во вмятину из бесконечно-малого смещения.
Напрямую к нашим магнитам, правда, такие рассуждения неприменимы, но моя мысль в том, что, вообще говоря, наличие в системе "невозможных" с точки зрения теоремы Ирншоу объектов типа банальных твёрдых деревяшек, на которые можно наклеить магниты — уже чит сам по себе даже в статике.
Вообще, при наличии гравитации не понятна причина, почему может не работать конструкция с "магнитной стенкой". Рассмотрим предельный случай: в сторону подпорки продлим невесомую ось ротора до условной бесконечности, а на конце соорудим наивную конструкцию с невесомыми отталкивающимися магнитами:
SN
NS===NS------NS SN
SN SN SN
1 2
Правая часть рисунка — не что иное, как повернутый на 90° левитрон, но если вертикальному левитрону нужно вращение для избежания опрокидывания, то лежащий должен стабилизироваться моментом оси: вниз его тянет гравитация, вверх возвращает момент от подвеса #2, к "стенке" его прижимает ротор, а к-нам/от-нас его стабилизируют те же моменты обоих подвесов, которые не дают горизонтально развернуться ротору.
Формально даже по старым стандартам проблем быть не должно, placement new начинает lifetime объекта (https://en.cppreference.com/w/cpp/language/new.html#Placement_new). Разве что с выравниванием могут быть проблемы, но по факту — в 90% систем и компиляторов всё тоже будет ок.
Нет, компиляторами ничего не игнорируется просто так, inline сейчас имеет просто другой смысл (выше написали про линковку), и к встраиванию не имеет никакого отношения. По-хорошему просто так его писать не нужно, иначе можно случайно замаскировать multiple definition error, который обычно выстрелит на линковке.
Запрос Double Click в принципе довольно странен и может насторожить (да и кто читает инструкции к капче?). Проще сделать вид, что кнопка "залипла" и не нажимается, и подменять окна только после нескольких яростных кликов (да — лаунчеры, меняющие фокус, я смотрю на вас с презрением и негодованием).
Выполняется. В демо видно, что после нажатия "Start Here" фейковая кнопка не активна в течение некоторого таймера — в это время, вероятно, под видимым окном грузится страница атакуемого сайта. В описании атаки тоже это проговаривается (не совсем очевидно, правда).
В самой статье сильно не хватает описания инструментария, доступного ИИ (хоть вы и ответили в комментарии выше, почему бы сразу не приложить этот промт в самой статье для желающих повторить эксперимент). Если ИИ доступен execute_code, то простор для решений довольно большой, вплоть до полного слома хостовой системы эксплоитами и прописывания себя в UEFI, например.
если представить элементы поля не в виде чисел, а в виде кортежей
Тогда это уже будет не поле целых чисел, а поле таких "кортежей" (кажется, полностью идентичное полю рациональных чисел). Вопрос просто в определении: по определению поля, множество целых чисел не является полем, так как частное от деления целых чисел может не принадлежать множеству целых чисел.
А, ну да, позволит, а рарчик просто открывался :) В статье ещё описывается использование WebRTC по UDP, у него тоже нет аналога CORS-ограничений вроде как.
Во-первых, открывать голые TCP/UDP соединения браузер всё-таки не позволит (если только через расширения конкретного браузера).
Однако, http-запросы из JS куда угодно разрешены, НО! CORS не позволит прочитать ответ внутри JS, если в ответе нет явного заголовка Access-Control-Allow-Origin: XXX. Да, в wireshark очень чётко видны открывающиеся TCP-сессии, запросы от браузера и радостные ответы локальных сервисов. Тем не менее:
остаётся возможность атаки по стороннему каналу (например, замеряем время запроса к http://127.0.0.1:5432 — косвенно понимаем, работает Postgres у пользователя локально или нет);
банально, всё ещё можно отправить запросы вида PUT http://192.168.0.1/login?user=admin&password=admin&set_dns=99.99.99.99 (зависит от API слушающих сервисов) — ответ нам вообще не важен, мы просто в лоб передаём в запросе нужную информацию слушающему сервису. Именно такой вектор обмена информацией рассматривается в статье.
Для меня лично стало неприятным сюрпризом, что
даже в современных браузерах есть возможность напрямую из песочницы обращаться к локальной сети и выполнять такой жирным пласт запросов (пусть и чаще всего односторонних);
и что CORS всего навсего блокирует ответы, но не запросы (что логично, но требует осознания).
Кстати, эту стереопару вполне можно рассмотреть и в миниатюрном варианте из статьи) Ну и да, она, в отличие от остальных фото в статье, предназначена для метода параллельного взгляда, а не перекрёстного.
Немного дополню озвученные ответы: да, "сила" объёмности зависит от т.н. стереобазы, то есть расстояния между фотоприёмниками (зрачками, объективами стереокамеры/бинокля и пр.). С помощью изменения этого расстояния в VR-приложениях настраивается масштаб сцены относительно пользователя: например, по умолчанию в Google Earth VR мир кажется игрушечным, потому что расстояние между камерами рендеринга равно десяткам/сотням метров, но активация режима "Human Scale" выставляет стереобазу в единицы-десятки сантиметров, что сразу меняет масштаб мира.
Увы, слишком короткая стереобаза (~6 см, межзрачковое расстояние) хоть и должна верно передавать масштаб, но делает два отрендеренных изображения слишком слабо различающимися, что при недостаточном разрешении дисплеев приводит к проблеме "плоской" сцены без параллакса — как в старых игрушках, когда пейзажи запекались в текстуру и натягивались на плоскость.
Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино, фотон… ну тут конечно погорячился).
Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?
Хорошая интерпретация “чёрного ящика”, имхо — не такой-то он и чёрный, и совсем не глупый (“ахаха, ИИ просто предсказывает следующий токен”).
На ум приходит ещё такая аналогия: если у XOR Problem есть вполне строгое решение на трёх нейронах, причём это решение находится обычным обучением нейросети обратным распространением ошибки, то почему бы не предположить, что (хотя бы) формальная логика не может быть с высокой точностью свёрнута и запечена в достаточно большую нейросеть? Между задачей “возьми со входов числа A и B и выдай на выходе A xor B” и задачей “возьми со входа формальное описание аксиоматики и теорему и выдай на выходе формальное доказательство этой теоремы” не такая и большая разница с точки зрения формализации.
Тут даже ещё интереснее — всё-таки заряд выскользнет перпендикулярно от оси, а не вдоль. Штош, интуиция тут и правда курит в сторонке.
UPD: там даже две седловые точки! Одна вертикально-стабильная, другая горизонтально-стабильная.
Хм, точно: если подвесить заряд над кольцом и подогнать массу, то это равносильно тому, что мы поместим невесомый заряд в центр кольца. И да, убежит он вверх или вниз, но прижимаясь к оси. Посыпаю голову точечными зарядами :)
Согласен. Но... меня терзают смутные сомнения, так как условия задачи уже не совсем в области определения теоремы Ирншоу: сама "твёрдая подпорка" уже невозможна в голой электростатике, так как внутри у неё всякая ковалентная и квантовая магия, чтобы существовал твёрдый материал, на который мы уже можем клеить магниты.
Например, заряженное кольцо:
Если картинка не обманывает, то есть эквипотенциальные поверхности, которые в 3D выглядят как "эритроциты" (таблетки с вмятиной), что явно говорит о потенциальной яме: градиент поля (следовательно, сила) в такой вмятине будет смещать пробный заряд ближе к оси... и нам осталось навесить сверху гравитацию, чтобы такой заряд не улетал от кольца, а возвращался во вмятину из бесконечно-малого смещения.
Напрямую к нашим магнитам, правда, такие рассуждения неприменимы, но моя мысль в том, что, вообще говоря, наличие в системе "невозможных" с точки зрения теоремы Ирншоу объектов типа банальных твёрдых деревяшек, на которые можно наклеить магниты — уже чит сам по себе даже в статике.
Вообще, при наличии гравитации не понятна причина, почему может не работать конструкция с "магнитной стенкой". Рассмотрим предельный случай: в сторону подпорки продлим невесомую ось ротора до условной бесконечности, а на конце соорудим наивную конструкцию с невесомыми отталкивающимися магнитами:
Правая часть рисунка — не что иное, как повернутый на 90° левитрон, но если вертикальному левитрону нужно вращение для избежания опрокидывания, то лежащий должен стабилизироваться моментом оси: вниз его тянет гравитация, вверх возвращает момент от подвеса #2, к "стенке" его прижимает ротор, а к-нам/от-нас его стабилизируют те же моменты обоих подвесов, которые не дают горизонтально развернуться ротору.
Да, а ещё
aligned_alloc, но в статье и комментарии обсуждается именно голый пример "malloc + c-tor", и вот для него формально не всё хорошо.Формально даже по старым стандартам проблем быть не должно, placement new начинает lifetime объекта (https://en.cppreference.com/w/cpp/language/new.html#Placement_new). Разве что с выравниванием могут быть проблемы, но по факту — в 90% систем и компиляторов всё тоже будет ок.
Нет, компиляторами ничего не игнорируется просто так,
inlineсейчас имеет просто другой смысл (выше написали про линковку), и к встраиванию не имеет никакого отношения. По-хорошему просто так его писать не нужно, иначе можно случайно замаскировать multiple definition error, который обычно выстрелит на линковке.Запрос Double Click в принципе довольно странен и может насторожить (да и кто читает инструкции к капче?). Проще сделать вид, что кнопка "залипла" и не нажимается, и подменять окна только после нескольких яростных кликов (да — лаунчеры, меняющие фокус, я смотрю на вас с презрением и негодованием).
Выполняется. В демо видно, что после нажатия "Start Here" фейковая кнопка не активна в течение некоторого таймера — в это время, вероятно, под видимым окном грузится страница атакуемого сайта. В описании атаки тоже это проговаривается (не совсем очевидно, правда).
В самой статье сильно не хватает описания инструментария, доступного ИИ (хоть вы и ответили в комментарии выше, почему бы сразу не приложить этот промт в самой статье для желающих повторить эксперимент). Если ИИ доступен
execute_code, то простор для решений довольно большой, вплоть до полного слома хостовой системы эксплоитами и прописывания себя в UEFI, например.Тогда это уже будет не поле целых чисел, а поле таких "кортежей" (кажется, полностью идентичное полю рациональных чисел). Вопрос просто в определении: по определению поля, множество целых чисел не является полем, так как частное от деления целых чисел может не принадлежать множеству целых чисел.
А, ну да, позволит, а рарчик просто открывался :) В статье ещё описывается использование WebRTC по UDP, у него тоже нет аналога CORS-ограничений вроде как.
Ответ сложнее и интереснее, чем может показаться.
Во-первых, открывать голые TCP/UDP соединения браузер всё-таки не позволит (если только через расширения конкретного браузера).
Однако, http-запросы из JS куда угодно разрешены, НО! CORS не позволит прочитать ответ внутри JS, если в ответе нет явного заголовка
Access-Control-Allow-Origin: XXX. Да, в wireshark очень чётко видны открывающиеся TCP-сессии, запросы от браузера и радостные ответы локальных сервисов. Тем не менее:остаётся возможность атаки по стороннему каналу (например, замеряем время запроса к
http://127.0.0.1:5432— косвенно понимаем, работает Postgres у пользователя локально или нет);банально, всё ещё можно отправить запросы вида
PUT http://192.168.0.1/login?user=admin&password=admin&set_dns=99.99.99.99(зависит от API слушающих сервисов) — ответ нам вообще не важен, мы просто в лоб передаём в запросе нужную информацию слушающему сервису. Именно такой вектор обмена информацией рассматривается в статье.Для меня лично стало неприятным сюрпризом, что
даже в современных браузерах есть возможность напрямую из песочницы обращаться к локальной сети и выполнять такой жирным пласт запросов (пусть и чаще всего односторонних);
и что CORS всего навсего блокирует ответы, но не запросы (что логично, но требует осознания).
Кстати, эту стереопару вполне можно рассмотреть и в миниатюрном варианте из статьи) Ну и да, она, в отличие от остальных фото в статье, предназначена для метода параллельного взгляда, а не перекрёстного.
Немного дополню озвученные ответы: да, "сила" объёмности зависит от т.н. стереобазы, то есть расстояния между фотоприёмниками (зрачками, объективами стереокамеры/бинокля и пр.). С помощью изменения этого расстояния в VR-приложениях настраивается масштаб сцены относительно пользователя: например, по умолчанию в Google Earth VR мир кажется игрушечным, потому что расстояние между камерами рендеринга равно десяткам/сотням метров, но активация режима "Human Scale" выставляет стереобазу в единицы-десятки сантиметров, что сразу меняет масштаб мира.
Увы, слишком короткая стереобаза (~6 см, межзрачковое расстояние) хоть и должна верно передавать масштаб, но делает два отрендеренных изображения слишком слабо различающимися, что при недостаточном разрешении дисплеев приводит к проблеме "плоской" сцены без параллакса — как в старых игрушках, когда пейзажи запекались в текстуру и натягивались на плоскость.
Почему-то прямо с порога некорректный ответ (
clang-trunk -O0):На
-O1и выше всё норм. UB таки стреляет?Для интересующихся — отличный перевод статьи 2018 года на Хабре про эту же технику:
Иллюзия пространства: как новый Spiderman рендерит помещения без геометрии
Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино,
фотон… ну тут конечно погорячился).Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?