На немецком «эйнштейн» звучит как «один камень». Один - «ein», камень - «Stain». Всем известно, что под этой фамилией жил один замечательный человек, и звали его ... Но в статье речь не о нём. Речь о математической задаче по поиску одной плитки, такой чтобы составленная из неё мозаика была непериодической. «Один камень» - это про плитку. В мозаике Пенроуза таких плиток две, а хотелось бы возможности использовать только одну. Не вдаваясь в детали можно сказать, что задача одной плитки в этом году (2023) решена. Получены интересные красивые мозаики.

Сначала была найдена «шляпа эйнштейна» - плитка, похожая на шляпу. Или, по моему скромному мнению, на рубашку. Из неё можно сделать отличную непериодическую мозаику. Только, для построения используются как сами шляпы, так и их зеркальные отражения. Считать ли это одной плиткой? Можно и не считать.

Дальше была найдена плитка «черепаха». Из неё тоже можно сложить непериодическую мозаику, по тем же самым правилам. Эти два вида плиток могут, плавно меняя форму, переходить друг в друга, меняя размер граней и при этом не меняя их направление. Ещё можно сложить непериодическую мозаику одновременно из этих двух плиток. Дальше больше. У такого плавного преобразования существует средний вариант, в котором длина граней одинакова.

Оказалось, такая мозаика, в которой есть одновременно и шляпы и черепахи, при обмене формой в момент, в котором длина граней становится одинаковой, составлена из плиток полностью одинаковой формы. То есть, существует ещё одна непериодическая мозаика, в которой плитка используется уже без своего зеркального отражения. Плитка, у которой грани модифицированы так, что она позволяет только непереодическое сложение названа «Spectre» (призрак). Задача решена, теперь уже точно.

Цель статьи

• Мониторный режим на встроенном адаптере
• Расшифровываем WPA трафик
• Ловим хендшейки и PMKID
• Собираем под макось пацанские тулзы: hcxtools, hashcat, bettercap
• Брутим хеши на онлайн-фермах и локально

Эта статья часть серии про порты игры Another World. В ней пойдёт речь про хитрости при работе с Amiga 500. Рекомендуется сначала прочитать предыдущую статью.

История Amiga начинается в середине 1982 года со звонка Ларри Каплана Джею Майнеру. Оба тогда работали в Atari в 70-х. Оба решили покинуть компанию. Каплан из-за отсутствия признания и Майнер из-за запрета руководства на использование крутого, но дорогого процессора Motorola 68000.

Покинув Атари, Каплан основал Activision. После того, как инвесторы обратились к нему с просьбой разработать новую игровую платформу, он связался с самыми блестящими людьми, которых он знал. Майнер взялся за аппаратную часть вопроса в только что образованной компании «Hi-Toro». Система получила кодовое название «Lorraine».

К концу 1983 прототип был собран. Устройство впечатлило посетителей Consumer Electronics Show (CES) в январе 1984 года, благодаря демке Boing Ball, в которой огромные спрайты перемещались с фреймрейтом 60 кадров в секунду. Устройство анонсировали в 1985 году под именем «Amiga from Commodore», позже переименовав в Amiga 1000.

TL;DR

Существует интересный способ изучения архитектуры компьютеров прошлого. Найти знакомую вам программу и попытаться выяснить, как она была портирована.

Хорошим выбором для этого мог бы стать DOOM. Мегахит 1994 года от id Software был портирован на всё, что только можно. Игра спроектирована вокруг ядра, чётко разделённого на слои. Обычно легко найти и прочитать реализацию шести подсистем ввода-вывода.

Другим выбором могла бы стать Another World 1991 года от Эрика Шайи, в Северной Америке более известная под именем Out Of This World. Я бы сказал, что на самом деле её интереснее изучать, чем DOOM, из-за полигональной графики, подходящей для диких оптимизаций. В некоторых случаях хитрые трюки позволяли игре работать на оборудовании, созданном за пять лет до выхода игры.

Привет, Хабр!

Уже довольно давно я пишу свой игровой фреймворк — такой pet project для души. А так как для души нужно выбирать что-то, что нравится (а в данном случае — на чём нравится писать), то выбор мой пал на nim. В этой статье я хочу поговорить именно про nim, про его особенности, плюсы и минусы, а тема геймдева лишь задаёт контекст моего опыта — какие задачи я решал, какие трудности возникли.

Давным-давно, когда трава была зеленее, а небо чище, я встретил nim. Хотя нет, не так. Давным-давно я хотел заниматься разработкой игр, чтобы написать свою Самую Классную Игру — думаю, многие проходили через это. В те времена Unity и Unreal Engine только-только стали появляться на слуху и, вроде как, ещё не были бесплатными. Я не стал их использовать, не столько из-за жадности, сколько из-за желания написать всё самому, создать игровой мир полность с нуля, с самого первого нулевого байта. Да, долго, да, сложно, зато сам процесс приносит удовольствие — а что ещё для счастья надо?

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

В целом эта функция обладает сомнительной прикладной полезностью, поэтому не удивительно, что в Linux готового аналога CreateRemoteThread нет. Однако, мне было интересно, как он может быть реализован. Изучение темы вылилось в неплохое приключение.

Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.

Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.

Эта статья основана на моём выступлении на конференции ITSubbotnik, прошедшем 2 ноября 2019 года в Москве.

Вообще я бэкенд программист, но меня заинтересовала эта технология, она позволяет использовать мои знания бэкенда на фронте.

Проблема

Начнём с проблемы, которая решается этой (относительно новой) технологией. Проблема эта — быстро исполнять код в браузере. Быстро — это значит, «быстрее чем JavaScript», в идеале настолько быстро, насколько позволяет имеющийся у нас процессор.

Мой дедушка в 60-х годах занимался разработкой компьютеров. Наводя порядок на его чердаке, я нашёл странную машину. Рядом с машиной лежала стопка перфокарт с пометкой “Dragon Adventure Game”. Спустя какое-то время мне удалось подключить её к современному оборудованию, но игра слишком сложная и я не могу добраться до конца без читерства. Сможете мне помочь? Прилагаю транскрипцию перфокарт, используемых в машине. Утверждается, что машина имеет 4 регистра общего назначения, 1 кибибайт памяти данных и 32 кибибайта памяти команд. Чтобы сыграть в игру, подключитесь к серверу следующим образом: socat tcp4-connect:cpuadventure.hackable.software:1234 fd:0,rawer Подсказка: процессор машины уникален, не пытайтесь гуглить информацию по нему.

game.bin