Сравнение процессоров Sun Sparc с процессорами МЦСТ-R

Недавно удалось получить удалённый доступ к компьютеру Дмитрия Бачило Sun Blade 1500 на процессоре Ultra Sparc IIIi, который выставляется в его недавно открытом музее, а также попросил пользователя Limows протестировать машину Netra T1 с процессором Ultra Sparc IIe 500 МГц. Плюс удалённо удалось получить результаты тестов процессоров серии МЦСТ-R на  архитектуре SPARC, поэтому я решил сравнить производительность процессоров от компании SUN (которую купил Oracle) и МЦСТ.

Компьютер Sun Blade 1500 в музее Дмитрия Бачило
Компьютер Sun Blade 1500 в музее Дмитрия Бачило

 

Характеристики сравниваемых процессоров:

 

Ultra Sparc IIe

Ultra Sparc IIIi

MCST R1000

MCST R2000

Архитектура

sparc

sparc

sparc

sparc

ISA

Sparc-v9

Sparc-v9

Sparc-v8

Sparc-v9

Микроархитектура

HummingBird

Jalapeno

In-Order

Out-Of-Order

Частота (МГц)

500

1500

1000

2000

Ядра; Потоки

1

1

4

8

Техпроцесс (нм)

180

130

90

28

TDP (Вт)

13

 

20

36

Тип ОЗУ

SDR PC-100

DDR-266

DDR2-800

DDR4-2400

Сокет

PGA 370

PGA 959

HFC BGA 1156

HFC BGA 1444

Каналов ОЗУ

1

2

1

2

Макс ОЗУ (ГБ)

2

16

8

128

Кеш

16 Кб L1I, 16 Кб L1D, 256 Кб L2

32 Кб L1I, 64 Кб L1D, 1 Мб L2

16 Кб L1I, 32 Кб L1D, 2 Мб L2 (512 x 4)

16 Кб L1I, 32 Кб L1D, 4 Мб L2 (512 x 8)

ГФлопс (DP)

0,5

1,5

8

32

ГФлопс (SP)

1

3

16

64

Транзисторов (млн.)

23

 

87,5

180

500

Год

2000

2003

2011

2019

 Были проведены следующие тесты:

  • 7zip встроенный бенчмарк

  • Dhrystone, Whetsone

  • Linpack 100

  • Coremark

  • Scimark 2

  • Stream, Memspeed

Результаты

1T — однопоточные тесты

MT — многопоточные тесты

 

Единица измерения

Ultra Sparc IIe

 

Ultra Sparc IIIi

 

MCST R1000

MCST R2000

 

OS

 

Linux 5.10

Sun OS 5.10

Linux 4.9

Linux 4.9

Compiler

 

Gcc 10

Gcc 4.9

Lcc 1.23

Lcc 1.23

Dhrystone (1T)

DMIPS

731

2455

1487

3491

Whetstone (1T)

MWIPS

457

1280

925

2289

Whetstone MP (MT)

MWIPS

457

1280

3515

17030

Linpack 100 (1T)

МФлопс

84

278

132

921

CoreMark (1T)

 

1299

3944

1861

4592

CoreMark MP (MT)

 

1299

3944

7157

35333

SciMark 2 (1T)

Composite

65

236

130

517

MFLOPS (MT)

МФлопс

 

906

6883

27500

7z (1T)

Total;

Compress;

Decompress

309;

268;

4193;

1111;

956;

13685

714;

585;

10219

1246;

990;

19146

7z (MT)

Total;

Compress;

Decompress

309;

268;

4193;

1111;

956;

13685

2514;

1884;

36020

8728;

7096;

135561

STREAM (MT)

МБ/с Copy;

Scale;

Add;

Triad

 

703:

645;

648;

617

 

 

 

Ниже результаты в виде графиков:

Сравнительный график однопоточных тестов
Сравнительный график однопоточных тестов
Сравнительный график однопоточных тестов приведённых к 1 ГГц
Сравнительный график однопоточных тестов приведённых к 1 ГГц

Подробные результаты смотрите здесь: anybench/results at master · EntityFX/anybench (github.com)

Немного об архитектурах процессоров UltraSparc II, III, МЦСТ-R

UltraSparc IIe 

Микроархитектура Ultra Sparc IIe
Микроархитектура Ultra Sparc IIe

Особенности процессора Ultrasparc IIe (Jalapeno):

  • 64 битная архитектура sparc-v9

  • FP/SIMD расширения VIS1, VIS2

  • Конвейер до 9 стадий

  • 6 исполнительных порта:

  • 2 целых АЛУ (сложение, сдвиг)

  • 1 АЛУ для умножения, деления

  • 1 Загрузки/Сохранения

  • 1 FPU/SIMD VIS

  • Кеши

  • 16  КБ L1 кэш команд (2 канальный, ассоциативный, размер линии 32 байта)

  • 16 КБ L1 кэш данных (прямая, размер линии 64 байта)

  • 2 КБ буфер подкачки, 2 КБ буфер записи

  • 256 КБ кэш L2 (4 канальный, ассоциативный)

Устройство конвейера Ultrasparc IIe: 

Конвейер UltraSparc IIe 
Конвейер UltraSparc IIe 

UltraSparc IIIi 

Конвейер UltraSparc IIIi 
Конвейер UltraSparc IIIi 

Особенности процессора Ultrasparc IIIi (Jalapeno):

  • 64 битная архитектура sparc-v9

  • FP/SIMD расширения VIS1, VIS2

  • Конвейер до 9 стадий

  • 6 исполнительных порта:

  • 1 целых АЛУ (сложение, сдвиг)

  • 1 АЛУ для умножения, деления

  • 1 Загрузки/Сохранения

  • 1 блок ветвлений

  • 1 FPU/SIMD VIS

  • Кеши

  • 32 КБ L1 кэш команд (4 канальный, ассоциативный, размер линии 32 байта)

  • 64 КБ L1 кэш данных (4 канальный, ассоциативный, размер линии 64 байта)

  • 2 КБ буфер подкачки, 2 КБ буфер записи

  • 1 МБ кэш L2

Устройство конвейера Ultrasparc IIIi:

Конвейер UltraSparc IIIi
Конвейер UltraSparc IIIi

MCST-R1000

Особенности процессора МЦСТ-R1000:

  • 64 битная архитектура sparc-v9

  • FP/SIMD расширения VIS1, VIS2

  • Конвейер до 9 стадий (7 целые, 9 вещественные)

  • Внеочередное исполнение

  • 4 исполнительных устройства:

  • 2 целых АЛУ

  • сложение, сдвиг, логика

  • сложение, сдвиг, логика, умножение, деление

  • 1 FPU/SIMD VIS

  • 1 Загрузки/Сохранения

  • Кеши

  • 16 КБ L1 кэш команд (2 канальный, ассоциативный, размер линии 32 байта)

  • 32 КБ L1 кэш данных (4 канальный, ассоциативный, размер линии 64 байта)

  • 2 МБ кэш L2

Устройство ядра МЦСТ-R1000:

Устройство кристалла МЦСТ-R1000: 

 Кристалла МЦСТ-R1000
Кристалла МЦСТ-R1000
Конвейер МЦСТ-R1000
Конвейер МЦСТ-R1000

MCST-R2000

Особенности процессора МЦСТ-R2000:

  • 64 битная архитектура sparc-v9

  • FP/SIMD расширения VIS1, VIS2

  • Конвейер до 9 стадий (7 целые, 9 вещественные)

  • Внеочередное исполнение

  • 4 исполнительных устройства:

  • 2 целых АЛУ

  • сложение, сдвиг, логика

  • сложение, сдвиг, логика, умножение, деление

  • 1 FPU/SIMD VIS

  • 1 Загрузки/Сохранения

  • Кеши

  • 32 КБ L1 кэш команд (4 канальный, ассоциативный, размер линии 32 байта)

  • 64 КБ L1 кэш данных (4 канальный, ассоциативный, размер линии 64 байта)

  • 2 КБ буфер подкачки, 2 КБ буфер записи

  • 1 МБ кэш L2

Ссылки

https://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/ultrasparc-iie-2516664.pdf

UltraSparc-II.pdf (chipdb.org)

UltraSPARC IIe User’s Manual (p0d.org)

Sun Microsystems UltraSparc IIe SME1701PGA-500 / SME 1701 PGA 500 MHz (cpu-world.com)

UltraSPARC IIIi Processor User’s Manual (yp.to)

Sun Microsystems SME1603uPGA-1503 / SME 1603 uPGA 1503 MHz (cpu-world.com)

R1000 (ТВГИ.431281.009) — центральный процессор 1891ВМ6Я (mcst.ru)

R2000 (ТВГИ.431281.024) — центральный процессор 1891ВМ018 (mcst.ru)


ссылка на оригинал статьи https://habr.com/ru/post/719610/

Интервью с одним из разработчиков игр инди-студии Creepy Brothers

Я продолжаю серию интервью с отечественными разработчиками игр. Не так давно на Хабре уже был материал про инди-студию Baba Yaga Games, потом про мобильных разработчиков Black Caviar Games. На очереди студия разработки, которая существует уже 13 лет  — это студия Creepy Brothers.

С ними тоже связана небольшая история. Когда я писал материал о Baba Yaga Games, то в статье было написано про зарубежную игру Creepy Tale. Однако оказалось, что один из разработчиков читает Хабр, и он мне написал в ЛС и комментариях, что эта игра российская. Я заинтересовался студией, и чтобы искупить свою ошибку, решил с ними пообщаться.  

У студии много игр, но, думаю, многие слышали про одну из титульных серий игр студии, а именно Creepy Tale (1 и 2 части). Эти игры даже мелькали у таких известных стримеров и летсплееров, как, например, Дмитрий Куплинов. И вот для большего погружения в интервью этой студии я решил поиграть в обе игры. Не без танцев с бубнами я купил игры (многие знают, что покупать сейчас в Steam игры не очень просто) и начал играть в первую Creepy Tale.

Поначалу я её расценивал как обычную игру, хоть и 2D. Типа пошёл туда, сделал это. Я настолько привык к обычным играм, где самая сложная загадка — это просто нажать нужные кнопки. Игра сама тебя ведёт и не даёт сильно задумываться. И с этой так же, я начал играть и что-то сначала пошло не очень, даже стиль не понравился, но потом зашло всё отлично, я быстро заинтересовался и втянулся. Для меня она оказалась немного сложной, хотя я отличным прохождением игр и не отличаюсь. Но оторваться я не мог. Что интересно, поначалу особых подсказок в игре нет, но если пользователь начинает подвисать, игра сама предлагает помощь. И да, можно подумать, что эта игра похожа на квесты из 90-х, и она правда похожа. Но основное в игре — геймплей, и он вполне увлекающий. Потом всё же пришлось оторваться, так как появились срочные задачи. Возможно, когда я её допройду, сделаю на неё полноценный серьёзный обзор.

После этого я решил запустить и вторую часть, чтобы сравнить изменения. Однако тут меня постигла неудача: на моём ноуте стоит M1 от Apple, а с ним, к сожалению, Creepy Tale 2 не идёт. И пока ребята не смогли пофиксить этот баг. Но ничего, когда возьмусь за обзор обеих игр, я её запущу уже на обычном Intel.

В остальном с другими играми студии я не ознакомился. Мне скорее хотелось больше поговорить про игры, которые дали название студии. Раньше она называлась по-другому и имела за плечами уже достаточно других различных игр, причём некоторые были тоже популярны.

Расскажите немного о вашей студии.

Занимаемся разработкой игр с 2010 года. Начали с флеша. Наклепали 50 игр. Среди самых успешных:

  1. Dangerous Adventure

  2. StrikeForce Kitty

  3. MadBurger

  4. Nelly

  5. Nordic Kingdom

Когда флеш начал умирать, мы стали осваивать Unity и покорять Steam.

Долго искали себя и наконец нашли. Стиль и название игры, изменившей всё, дало нашей студии новое имя — Creepy Brothers. (до этого было Deqaf Studio — за которым не стояло никакого смысла).

Какой сейчас штат у студии?

Три человека. Программист, Художник и Звукорежиссёр. Все мы проживаем в разных городах, но такой формат не мешает, а наоборот, только ускоряет процесс разработки, конкретно в нашем случае уж точно.

Все мы фанатики своего дела и отдаёмся созданию игр полностью — это просто наш стиль жизни. Конечно, нам уже не 20 лет и сидеть за ПК круглыми сутками не выходит. Но ты постоянно думаешь об игре, это часть тебя.

Скажите, вы делаете игры на заказ или только собственные произведения?

Мы творим исключительно для себя. Это наше развлечение, отдых, хобби и работа в одном флаконе.

Вы говорили, что вдохновлялись различными сказками, в ваших пресс‑релизах говорится, что больше упор на братьев Гримм и Шарля Перро, а в интервью вы упоминали Волкова и Толстого (Алексея). Упор больше на какие сказки — зарубежные или отечественные — или 50/50?

Сейчас упор больше на собственные идеи и истории. Не хочется создавать игру как набор отсылок. В Creepy Tale 3 за основу взята завязка из сказки Андерсена про девочку, наступившую на хлеб. На этом сходство заканчивается.

Первая игра была разработана на Unity, вторая тоже создавалась на этом движке? Планируете ли вы переходить на Unreal Engine?

Для наших задач менять движок нет никакого смысла. 2D-игры прекрасно создаются на Unity.

Ваши игры выпущены только на ПК и консолях; скажите, планируете ли вы выходить на мобильные платформы? Будете ли вы делать кросс‑платформенные игры (и для ПК, и для мобильного сегмента)?

Не люблю мобильный рынок и не стремлюсь выпускать на нём свои игры. Не исключаю, что когда‑нибудь это и произойдет, но сейчас мы сфокусированы исключительно на ПК. С консолями стало очень сложно.

Ваша игра Creepy Tale 2 не работает на процессорах М1 от Apple, скажите, получилось решить эту проблему?

К сожалению, нет. Компьютера от Apple нет, и собрать сборку просто нет возможности. А сборка через Unity Cloud выдаёт подобную ошибку. Возможно, они решили проблему, но мы уже не имеем подписки и не можем купить новую.

Какими мультфильмами, художниками или другими произведениями вы вдохновляетесь при создании своих игр?

Сложный вопрос. Вдохновляемся всем. Всем, что попадется под руку. Порой и серьёзная книга на совершенно иную тему подкидывает идейки.

Нам очень нравятся творения Amanita Design. Но, если честно, мы сейчас почти не играем.

Вы говорили в одном из своих интервью, что история в Creepy Tale 2 закончена, и вот анонсирован Creepy Tale 3. В ней будет свой сюжет?

Да, мы решили превратить Creepy Tale в цикл жутких игр, не связанных сюжетно между собой, но выполненных в одном стиле. Все события, конечно же, происходят в одном мире, и игроки смогут найти отсылки к другим частям.

Сотрудничали ли вы со студиями озвучки при создании Creepy Tale 3, как это было в Creepy Tale 2? С той же польской студией или какой‑то отечественной?

Вы имеете в виду голосовой озвучки? Польская студия была нанята нашим издателем на консоли из Польши. Голосовая озвучка для Creepy Tale 3 писалась уже в России профессиональными актерами на студии озвучания «Ravencat». В игре будет русская и английская голосовая озвучка. А вот субтитры будут ещё и на китайском, испанском, немецком.

Наш Каст:

Ева Финкельштейн: Ингрид (русская), Душа мальчика(английская).

Кристина Шерман: Ингрид (английская), Болотница, Душа мальчика (русская).

Пётр Коврижных: Млох, Истукан. (русская и английская)

Сергей Пономарёв: Дедуля, Столяр, Смотритель. (русская и английская)

Маргарита Корш: Тётушка Зубная Боль, Мама, Бабка. (русская и английская)

Михаил Хрусталёв: Торговец, Филин. (русская и английская)

Дохода с продажи игр в различных цифровых магазинах вам хватает на разработку новых игр? Или у вас есть ещё какие‑то донатные площадки, куда вам скидывают люди для поддержки создания игр?

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

Сейчас в условиях санкций сложно покупать игры, особенно в ушедших магазинах? Вы планируете выход в VK Play? Как можно приобрести ваши игры сейчас?

Продажи в VK Play настолько малы, что говорить про них без иронии сложно. Да, игры покупать стало сложно, но продажи в Steam говорят о том, что нашим людям всё нипочем.

Вы российская компания? Если нет, не могли бы рассказать, почему?

Да, мы все из России. Уезжать не планируем.

Будет ли Creepy Tale 4? Или игра в том же мире, но с другим названием?

Будет! Идей много, и, если честно, не терпится уже приступить к разработке новой игры. Очень уже устали мы смотреть на нашу Creepy Tale 3…

Поймал себя на мысли, что, похоже, не будет вообще больше игры с другим названием. Но и не будет цифр. Что‑то в духе «Creepy Tale: (название)».

Собираетесь ли вы что‑то черпать из сказок народов России, как это делает, например, студия BABA YAGA GAMES?

Не исключаю. Возможно, когда‑нибудь будет целая игра в сеттинге сказок народов России. Там есть где развернуться, но у нас и так аудитория в основном из России, а очень хочется достучаться и до зарубежной аудитории. Не исключаю и сеттинг в восточном стиле. Жутких историй там тоже хватает.

Что бы вы посоветовали начинающим инди‑разработчикам?

Обращаюсь к тем, для кого игры — это творчество, а не бизнес.

Первый проект должен быть небольшим и простым. Главное — доведите его до ума и отполируйте до блеска. Затем выпустите без сожалений и принимайтесь за новый. По‑другому опыт не получить. Внимательно изучайте игры, которые являются для вас примером. Всё строится из мелочей. Из огромного количества мелочей. Удачи!

Довольно увлекательно читать людей, у которых горят глаза, даже когда ты просто общаешься с ними по переписке. К сожалению, я взял интервью у ребят, когда они были в процессе кранча, так как доделывают Creepy Tale 3. Поэтому студии пришлось оторваться от работы и потратить драгоценное время на меня. Однако сейчас они выпустят третью игру в серии Creepy Tale и, возможно, я ещё их расспрошу про новую игру и сделаю её обзор с комментариями авторов. Вообще, по моему мнению, стиль игр Creepy Brothers Studio претендует на мерч, много разного мерча. Уж очень у них странный стиль, но подходящий под футболки, кепки и так далее, даже мягкие игрушки. Вон, Хаги‑Ваги был популярен. Понятно, что разработчикам игры бы выпустить, но как дополнительная копеечка для улучшения рабочих условий и в целом дополнительный капитал — всегда хорошо.

И вот в очередной раз я убеждаюсь, что для хорошей игры достаточно просто сделать нормальный геймплей. Ведь многие играют в игры ради игры. Да, иногда сюжет намного интереснее игры. Однако в последнее время как раз инди‑сегмент даёт насладиться процессом геймплея. Да, у ААА‑сегмента получается (привет, Hogwarts Legacy и Atomic Heart), но это скорее погрешность, потому что над ААА‑разрабочиками стоят менеджеры, графики, фокус‑группа, инвесторы. Это очень сильно ограничивает творчество, но это разговор отдельного материала и скорее к Джейсону Шрайеру.

А так — удачи парням Creepy Brothers Studio, надеюсь, Creepy Tale 3 не разочарует.


ссылка на оригинал статьи https://habr.com/ru/post/719622/

Его величество Пайп, или как заставить ssh tunnel открыть RDP на другом конце через альтернативный IP

Немного теории

Для начала, вспомним некоторые базовые вещи ОС Unix.

Любой процесс в Unix имеет три открытых файла по умолчанию, (но он может их потом закрыть/переоткрыть, например перенаправляя вывод в log file):

  • 0 (stdin)

  • 1 (stdout)

  • 2 (stderr)

примечание: stderr, отличается от stdout тем, что он не использует буфер для вывода.

Процессы unix могут выполняться асинхронно, как параллельно, так и последовательно, например:

$ cmd1 & cmd2;(cmd3 && cmd4) & (cmd5 || cmd6)

Разберем приведенную вязь команд по косточкам:

cmd1 & cmd2; — вначале параллельно запустятся cmd1 и cmd2

(cmd3 && cmd4) & (cmd5 || cmd6) — после завершения cmd1,параллельно запустятся условные цепочки cmd3,cmd4 и cmd5,cmd6. При этом:

cmd4 запуститься если cmd3 завершиться успешно, то есть ее код возврата будет 0,

cmd6, только в том случае, если cmd5 вернёт ненулевой код возврата.

Мне нравится термин конвейер для таких цепочек команд.

Pipe

Конвейер, помимо асинхронного выполнения, может синхронизировать выполнение процессов по вводу/выводу, используя специальный тип файла: pipe, или по русски канал.
Pipe — специальный тип файла, реализующий очередь FIFO (First Input, First Output) в Unix. Pipe может быть именованным или нет. Проще всего перенаправлять стандартные открытые файлы.

Неименованные каналы

Используя различные комбинацию конвейера и каналов, можно решить самые разные задачи администратора. Приведу примеры из собственной практики синхронизации через неименованные каналы:

## вывод размера файлов и числовая сортировка (про ключи -sS команды ls в курсе) $ ls | awk '{printf("%25d %s\n",$5,$9)}'|sort -n
## найти пакеты postgresql $ apt list | grep postgresql
## сформировать SQL команды для переноса файлов oracle ##  из одной файловой системы в другую. $ (echo "set line 1000 pages 0 feedback off";echo "select 'alter database rename file '''||name||''' to '''||replace(name,'/u/','/u00/')||''';' as cmd from v\$datafile where name like '/u/%';")|sqlplus -s -l / as sysdba
## пример пробрасывания канала с одного host на другой из разных сессий ## префикс приглашения показывает hostname сервера ## на котором запускается команда host2$ nc -l -p 44665|tar xvf - host1$ tar cvf - /home/mydata | nc host2 44665

Прокомментирую последний пример: Тут используется команда netcat (или nc), которая открывает сетевой канал для проброса канала tar/untar.

При копировании больших объёмов, это может дать в разы большую скорость, чем стандартное scp. Например, у меня при копировании 1500G backup database c одной VM на другую, скорость выросла в пять раз без сильной нагрузки на CPU.

Понятно, что при копировании между ЦОД, нужно учитывать открытость такого трафика для перехвата.

Именованные каналы

Когда команды запускаются из под одной учетной записи, и команды работают с нужной информацией через stdin/stdout, особых проблем нет. Но вот реальный пример, когда oracle imp, умеет писать dump последовательно только в файл, которые указан параметром FILE=.
У вас не хватает пространства, чтобы выгрузить нужные данные, но можно сжать полученные данные используя Named Pipe и потоковую компрессию данных.

## Для начала создадим  канал как элемент файловой системы  ## используя команды mkfifo или mknod $ mknod exp.dmp p
## запускаем в фоновом режиме gzip с чтением из именованного файла $ gzip -c < exp.dmp > exp.dmp.gz &
## запускаем oracle exp с выводом в Name Pipe $ exp file=exp.dmp userid=/ tables="(DROPME1,DROPME2)"

Как сделать exp из полученного архива, предлагаю подумать самим в качестве задания.

Разумеется, с именованными каналами, можно использовать netcat, для организации межсерверной коммуникации.

SSH туннели

ssh — универсальный инструмент администратора. В стандартной реализации ssh, существует возможность создать специальный шифрованный канал — ssh tunnel.

Пример использования ssh tunnel для проброса VNC:2 удаленного порта 5902 доступного только для 127.0.0.1 на vm2 на локальный порт 5902 машины vm1. После входа на vm2 командой:

vm1$ ssh -L localhost:5902:localhost:5902 user@vm1

вы можете запустить на vm1 локальный vncviwer :2 и попасть на vnc:2 на машине vm2.

 vm1$ vncviwer  localhost:2 

Схематично это можно показать так:

Здесь через локальный порт (-L) подключались к удаленному через ssh tunnel.

Для проброса удаленного порта (-R) на пользовательский комп, поступают аналогично. Например надо подключится к домашней postgresql базе с рабочего компа подключившись из дома к рабочей машине:

my1$ ssh -R localhost:5432:localhost:5432 user@vm1  vm1$ psql -h localhost -p 5432

Здесь мы свой домашний 5432 порт пробрасываем на удаленную машину.

Более сложный пример (начало):

По проекту, потребовалось RDP подключение с рабочего notebook через VPN и цепочку hosts на windows машину. При этом, напрямую подключиться к каждой из цепочки машин невозможно, только последовательно.

В целом, подключение выглядит так :

Идем стандартным путем, используем туннель + ssh jump:

## команда, которой я пользовался для подключения:  my$ ssh -i ~/.ssh/vm1.key -J gateuser@gatehost -L 127.0.0.1:3390:win1:3389 user@vm1 

Где:

-i vm1.key — файл private key пользователя user@vm1

-J (Jump), подключится к user@vm1 через  gateuser@gatehost, само подключение к gateuser@gatehost, так как постоянно работаю через него, прописано у меня в ~/.ssh/config

-L 127.0.0.1:3390:win1:3389 — создание сквозного ssh tunnel между my (127.0.0.1:3390) и (win1:3389) через машину user@vm1. То есть, пробрасывается открытый на vm1 конец канала vm1:3389 — win1:3389

## осталось подключится по RDP: my$ xfreerdp /scale:140 /u:winuser /smart-sizing:1900x1000 /size:1900x1000 /bpp:32 /network:lan /p:**** /v:127.0.0.1:3390

Пример (продолжение):

Все работало отлично, но в один из черных дней погибает vm1…

Сервера расположены не у нас, процедура перенастройки требует согласования и времени, вот только доступ на win1 понадобился вот прямо сейчас!

Рядом с vm1 расположен еще один сервер vm2, но доступа с его IP на win1 нет.

Было принято решение (с получением «добра» от начальника), поднять второй IP от первого vm1 на втором vm2 и ходить через него.

Сеть наша, лишних в ней нет, поэтому: сказано — сделано:

# добавляем второй IP vm2$ sudo ip a add 192.168.45.56/24 dev eth0
## проверяем vm2$ ip a ... 2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000 ...   inet 192.168.45.57/24 brd 192.168.56.255 scope global eth0 ...   inet 192.168.45.56/24 scope global secondary eth0  ...

Вот только засада, ssh не умеет указывать какой IP использовать при подключении через ssh tunnel.

То есть при попытке подключения предыдущей командой окончилось неудачей, так как соединение к win1 идет через default IP ( для этого сервера 192.168.45.57),  а «волшебного ключа», для указание ssh tunnel через какой удаленный IP ему подключаться дальше — не существует в текущей версии ssh. Ключа —remote-bind-address — не существует:

## таких не бывает! $ ssh -J ... -L localhost:3390:win1:3389 --remote-bind-address 192.168.45.56 user@vm2

Начались поиски решения, найденные варианты не подошли по разным причинам:

  • route add --host

  • iptables -t nat -I POSTROUTING

Но все нашли решение.

Помог netcat + named pipe. Итак вот оно, решение!:

## создаем на vm2 uniх name pipe vm2$ mkfifo /tmp/rdp.pipe
## запускаем двухстороннее перенаправление ## localhost:3389<->win1:3389 через созданный rdp.pipe vm2$ nc -v -n -s 192.168.23.1 192.168.45.56 3389 <0 /tmp/rdp.pipe |nc -lkv -n -s 127.0.0.1 -p 3389 1> /tmp/rdp.pipe  ## проверяем  vm2$ sudo netstat -anp | grep 3389 tcp    0  0 127.0.0.1:3389      0.0.0.0:*           LISTEN  15460/nc          tcp    0  0 192.168.45.56:42175 192.168.45.111:3389  ESTABLISHED 15459/nc
## Чуток модифицируем предыдущую команду для ssh tunnel ## так как теперь RDP у нас на localhost:3389 сервера vm2 ## и только потом через nc + rdp.pipe идет подключение на win1:3389  my$ ssh -i ~/.ssh/linuxhostkey -J gateuser@gatehost -L localhost:3390:localhost:3389 user@vm2
## на my notebook подключаемся через RDP my$ xfreerdp /scale:140 /u:winuser  /smart-sizing:1900x1000 /size:1900x1000 /bpp:32 /network:lan /p:***** /v:127.0.0.1:3390

Как заключение

Я в принципе знал сам принцип, но вот использовать такой трюк для проброса RDP между локальными IP не додумался, да и на удивление, такое решение нашлось далеко не сразу.

Надеюсь, данная статья поможет многим администраторам разобраться с каналами, и их использованием в своей работе.


ссылка на оригинал статьи https://habr.com/ru/post/719628/

Исследование винтажной компьютерной техники: 4 бита драконов: игра-лабиринт Dungeons & Dragons от Mattel

Когда мои родители продали дом и перебрались на белоснежные просторы Великого севера, они вывезли несколько коробок моего барахла, которое долго пылилось в гараже. Мы сейчас разбираем вещи и роемся в этих коробках на случай, если в не столь далёком будущем нам самим понадобится переехать. В одной из коробок нашлась моя старая компьютерная игра-лабиринт DUNGEONS & DRAGONS™ от Mattel Electronics.

Это большая, «делюксовая» из двух игр D&D от Mattel (у Intellivision, конечно, был свой набор, а у нас был Tandyvision), вторая — DUNGEONS & DRAGONS™ компьютерная игра в жанре фэнтези. Это было портативное устройство с неожиданно привлекательной реинкарнацией игры Hunt the Wumpus, о которой мы поговорим в другой раз. Эта игра больше похожа на настолку, но в ней есть компьютерный антагонист и звуковое сопровождение.

Слово «реализация» заменено на слово «реинкарнация», поскольку, как нетрудно понять из одноимённой статьи, эти игры имеют очень мало общего, за исключением общей идеи охоты на монстра в лабиринте https://ru.wikipedia.org/wiki/Hunt_the_Wumpus.

На коробке написано «copyright 1980», но мне кажется, мы купили её в конце 1982 или в начале 1983 года. Как бы то ни было, я, наверное, тогда был маловат для такой игры: в рекламе говорилось «от 8 и старше», а мне было всего шесть или около того. В ней нужно было руководствоваться несколькими звуковыми сигналами и строить лабиринт с объектами в нём (вы, ваш соперник, дракон, сокровище и прочее подобное). Насколько я помню, мы в эту игру почти никогда не играли.

Ну что ж, лучше уж поздно, чем никогда. И, да, давайте выясним, на чём эта штука работает. (Тизер: на четырёх битах и у нас есть фото кристалла микросхемы с подписями. Читаем дальше).

Углы этикетки были слегка загнуты, но я подмазал её клеем-карандашом, в остальном она как новая, и все элементы игры на месте. В 1982 году рекомендованная цена игры была 55 долларов, а в 2023 году — все 170. Игра, определённо, должна излучать флюиды премиум-класса, чтобы оправдать такую цену (подозреваю, что мои родители купили её на одной из распродаж Kaybee Toys). Элементы игры лежат в удобном выдвижном ящичке.

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

Как ясно из названия, в сердце игрового процесса — пошаговое прохождение лабиринта в подземелье восемь на восемь клеток. Зубцы между клетками поля служат для установки между ними красных «стен», на которые вы будете натыкаться, когда выстроите лабиринт визуально. Игра сообщает нам о происходящем двенадцатью уникальными звуковыми сигналами. Поскольку нам нужно знать их значения, шесть нижних клавиш в левом ряду воспроизводят их по требованию (нажатием кнопки SWITCH мы переходим к следующим шести сигналам). Однако все они хорошо различимы и их значения угадываемы, поэтому я не припомню, чтобы у нас были какие-то проблемы с их запоминанием. Основная цель игры — добыть сокровища и вернуться с ними в своё убежище раньше, чем до них доберётся другой игрок, и раньше, чем дракон доберётся до вас. На повышенном уровне сложности появляются «двери», которые открываются и закрываются случайным образом. Однако это раздражает, и я уверен, что в таком режиме мы играли ровно один раз. Приличную партию вы, вероятно, сможете разыграть за 10–15 минут.

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

Игра запитана от одной 9-вольтной батарейки, но вы можете подключить адаптер переменного тока (в комплекте его нет). На наклейке написано, что нужно заменить батарейку, если игра начинает вести себя странно. Вот это я охотно сделал бы со своей кошкой, но понятия не имею, где у неё спрятан батарейный отсек.

Mattel’овский шифр изделия выдавлен в пластике (1991-2109-E © MATTEL INC. 1980).

Фигурки довольно симпатичные. Они отлиты из металла и чувствуется приятная тяжесть. Не сомневаюсь, что вес помогает игре обнаружить их присутствие в игровых локациях, а игрокам — понять, что они купили не хлам. Вот дракон. Он проработан до мельчайших деталей.

Вот ~мышки на корм этому дракону~ бесстрашные воины.

А вот вожделенные сокровища.

Три зелёных жетона обозначают тайные комнаты игроков (начальная и конечная позиции) и местоположение сокровищницы, чтобы вернуть туда сокровища, если незадачливому герою не удастся выбраться с ними из лабиринта. Фигурка сокровищ здесь в основном для вида. Игрок, овладевший сокровищами, заберёт её себе, оставив на её месте зелёный жетон. Но выглядят они классно.

Вскрытие игры больше всего затрудняют вот эти защитные винты Mattel. Они же какое-то время использовались в картриджах Intellivision. На форумах полным-полно вопросов о том, какой насадкой их отвинтить. Точно под их резьбу не подошла ни одна из них, но, кажется, чтобы вскрыть игру, почти не повредив резьбу, достаточно хорошо подошла моя отвёртка TA2.7.

Винты вывернул, ящик достал, батарейный отсек открыл. Но это ещё не всё!

Развинченный корпус всё ещё крепко держится набором очень тугих пластиковых замков. Мне понадобилось добрых десять минут возни с пластиковым шпателем и нейлоновой монтажной лопаткой, чтобы крякнуть этот корпус (и крякал он при этом не раз. Поддевать корпус металлической лопаткой или шлицевой отвёрткой не надо, не надо и ещё раз не надо. Пластмасса очень легко гнётся. Даже я немного повредил его нейлоновым инструментом, но, по счастью, видно это только тому, кто знает, куда смотреть. Дольше всего пришлось потрудиться над той стороной, где был ящик. Место соединения двух половин утоплено, и вам действительно придётся втирать туда свой рабочий инструмент.

Половинки корпуса разделены. Это игровой планшет (а по сути клавиатура с мембранной плёнкой).

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

В остальном компонентов очень мало. Динамик — здесь он остался слева за кадром — посажен на то, что когда-то, видимо, было монтажной шпатлёвкой, а теперь высохло до состояния рыхлого крошащегося комка. Кроме нескольких разбросанных по плате резисторов, пары конденсаторов и биполярного транзистора 2N2222, на плате «доминирует» 28-выводная микросхема производства Texas Instruments c обозначением M34012-N2LL в плоском DIP-корпусе, датируемый 23-й неделей 1982 года (что соответствует моим воспоминаниям о времени покупки игры). Батарейный отсек подключён к небольшому коммутатору справа.

DIP означает «dual in-line», данное сокращение обозначает самый распространённый тип корпуса — плоский, с параллельными выводами вдоль длинных сторон корпуса.

На нижней стороне платы — маркировка «MATTEL, INC. © 1980 1991-9229 REV-C». Отверстие с маркировкой FR на самом деле пустует. Просто на этом фото через него отсвечивает отражение ленточного разъёма. Судя по тому, что я здесь вижу, разъём питания должен быть с положительным полюсом на концевом контакте и тоже 9-вольтным (в руководстве об этом ничего не сказано). Ну что ж, 9-вольтные батарейки недорого стоят.

Теперь о центральном процессоре. Хотя по номеру микросхемы можно отнести его к Texas Instruments TMS34010, для них микросхема и слишком маленькая, и слишком древняя. Для детской игрушки нужно что-то простое, недорогое и массовое, и у Texas Instruments есть очень подходящий вариант.

M34012 — это, по сути, итерация микроконтроллера Texas Instruments TMS1100, который, в свою очередь, развился из TMS1000 и произошёл от TMS0100, который в 1971 году был первым в мире микроконтроллером. В этих кристаллах ОЗУ, ПЗУ и средствам ввода и вывода находятся в одном кристалле с поддержкой сегментных дисплеев и считывания нажатий. При этом требования к внешней элементной базе очень малы. Впервые TMS0100 использовали (под шифром TMS1802NC) в новаторском для своего времени карманном калькуляторе Sinclair Executive, и с этой задачей схема справилась отлично. Texas Instruments переработала конструктив TMS0100, что в 1974 году дало начало «производственной линейке» TMS1000. А в 1975 году фирма слегка модернизировала ОЗУ и ПЗУ и выпустила серию TMS1100. Микросхема M34012 спроектирована на основе p-МОП транзисторов, что позволяет ей запитываться практически напрямую от 9-вольтной батареи или другого нестабилизированного источника с близким напряжением.

Реже применяемый по сравнению с n-МОП, p-МОП — это тип транзистора, где основными носителями заряда являются не электроны, а дырки, а внутренняя ёмкость, как правило, выше.

В отличие от другого нашего любимого игрового микроконтроллера, изготовленного по техпроцессу MOS Technology 7600, по которому никто не нашёл ни краткой спецификации, ни даже рекламного проспекта, по семейству TMS1000/1100 документации столько, что её хватит даже для упрощения написания MAME-драйверов для таких игр. Программируемая логическая матрица (ПЛМ) на выходе и даже ПЛМ дешифровки инструкций были настраиваемыми: пришлите обе ПЛМ и масочное ПЗУ в Texas Instruments вместе с пачкой денег и вы получите огромное количество тестовых игровых контроллеров практически едиными блоками. Texas Instruments использовали их не только в своих собственных игрушках Speak & Spell для потребительского рынка, но и для игры Simon от Milton Bradley (теперь — Hasbro), видеоигры Merlin от Parker Brothers и Microvision от Milton Bradley, первой игровой консоли со сменными картриджами (после того как энергопотребление 8021-го процессора Intel оказалось слишком высоким). К 1979 году фирма Texas Instruments уже не в первый раз раз продала около 26 миллионов схем этого семейства в год, а в конце восьмидесятых использовались уже её более новые версии, созданные по техпроцессам n-МОП и КМОП (комплиментарный МОП-процесс, то есть построенный на парах транзисторов n-МОП и p-МОП).

Вот снимок топологии кристалла M34012, любезно предоставленный Шоном Риддлом, у которого есть снимки кристаллов целого ряда подобных схем. Я описал кристалл по руководству программиста и раннему патенту Texas Instruments, где был изображён кристалл TMS1000. Самые крупные участки на кристалле занимают 512 бит ОЗУ (организованные в 128 тетрад [1 тетрада (nybble) = 4 бита или пол-байта]) и 2 Кб масочного ПЗУ

Запись информации в ПЗУ производится в процессе изготовления микросхемы — при формировании металлизации. Используются для хранения данных, которые не потребуется изменять

А ещё 64 тетрад и 1 Кб ПЗУ в TMS1000, а также две ПЛМ.

Тактовая частота MAME оценивается в 475 кГц, что основано на номинальных значениях ближайших к кристаллу резистора и конденсатора, хотя это значение и имеет тенденцию к колебаниям. Все инструкции выполняются в один такт. Микросхема имеет 4 входа (K-входы для клавиатурных рядов) и 19 выходов, объединённых в две группы, одна группа из 8 одновременно задаваемых из выходного пятибитного регистра на выходе ПЛМ (O-выходы) и 11 управляемых индивидуально (R-выходы). В Texas Instruments R-выходы предусмотрены для управляющих шин, а O-выходы — для светодиодной индикации. Тем не менее в данной игре все O-выходы и почти все R-выходы (кроме одного, идущего к динамику) обслуживают клавиатуру. Поскольку входа четыре, клавиатура делится на две половины и каждая состоит из четырёх строк [это видно в том же файле Шона Риддла по ссылке]. Рабочее напряжение в игре подаётся по отдельной выходной шине на каждый из 9 столбцов в каждой половине (таким образом, всего используется 18 шин). Нажатия кнопок передаются обратно на K-входы.

В схемах семейства TMS1000 используется гарвардская архитектура:

https://ru.wikipedia.org/wiki/Гарвардская_архитектура — архитектура с двумя шинами, отличительной особенностью которой является то, что для лучшей производительности используются две памяти (память команд и память данных), а также раздельные шины адреса и данных для доступа к ним.

Поэтому ПЗУ имеет отличный от ОЗУ диапазон адресов. TMS1000 работает с 43 инструкциями, 12 из которых управляются фиксированной логической схемой, а остальные ставятся в очередь ПЛМ (в TMS1100 их число увеличено до 54, и некоторые из них несколько видоизменены). Как и большинство фирм, Mattel использовала один из стандартных дешифраторов команд в виде ПЛМ Texas Instruments, а не заказывала кастомизированный. Каждая схема семейства TMS1000, включая ту, которую мы рассматриваем, имеет на выходе кастомизированную ПЛМ, что продиктовано сложностями преобразования данных из 5-битного формата в 8-битный. Для игры через MAME требуются ПЗУ и содержимое обеих ПЛМ.

В 1970-е годы родилось много странных архитектур, но семейство TMS1000 — безусловно, одно из самых странных. У TMS1000 — 4-битный накопительный регистр (accumulator — A),4-битный Y-регистр (Y), 2-битные (в TMS1100 их три) X-регистр (X) в качестве регистра адреса страницы ОЗУ, 6-битный программный счётчик (program counter — PC), 6-битный регистр возврата из подпрограммы (subroutine return register — SR, иными словами, регистр связи), 1-битная защёлка вызова (call latch — CL) во избежание случайной перезаписи SR, 4-битный регистр адреса страницы ПЗУ (ROM page address register — PA), 4-битный буферный регистр страницы ПЗУ (ROM page buffer register — PB, также используется с регистром возврата из подпрограммы), 5-битный регистр O-выходов (O), единственный бит состояния (S) который по умолчанию установлен в значение true и по биту для каждого R-выхода, индексируемого по Y (R(Y)). (K-входы считываются при помощи специальных инструкций).

Хотя каждая инструкция весит всего один байт, в схеме используется 6-битный программный счётчик, что означает, что передавать можно всего 64 байта ПЗУ, поэтому PA выбирает одну из 16 страниц. При запуске PA задаётся страница 15, а PC — 0. Программный счётчик зацикливает данные, то есть после 63-го байта идёт 0-й на той же странице. Кроме того, единственные команды перехода работают при бите состояния S в значении true. Для длинного перехода [перехода на адрес в другом сегменте памяти] или вызова нужно обеспечить S = true (то есть при необходимости нужно выполнить холостую или заведомо истинную инструкцию), задать PB желаемую страницу (LDP x) и затем выполнить переход (BR): центральный процессор поместит данные PB в PA и на новой странице начнёт отсчёт с нового PC. Вызовы (CALL) для сохранения адреса обратного перехода выполняют подкачку регистров PB и PA, таким образом вы не сможете выполнить длинный вызов в рамках подпрограммы, и, пока инструкция RETN не очистит защёлку CL, последующие вызовы не изменят значений SR и PB, которые будут, как и прежде, указывать на начальный адрес обратного перехода и страницу. После выполнения перехода, прошедшего или нет, бит состояния S снова устанавливается в true.

Исполнение программы в TMS1100 несколько усложняется: ПЗУ там дублируется, поэтому для нового второго банка добавлен набор однобитных защёлок глав (chapter latches). По аналогии с SR, PA и PB здесь у нас есть CS (chapter subroutine, подпрограмма главы), CA (chapter address, адрес главы) и CB (chapter buffer, буфер главы), все они включены, и все имеют логическое состояние «ноль». Новая инструкция COMC переворачивает значение CB. При переходе (branch) CA задаётся значение CB, а PA — значение PB. При вызове (call) CS тоже задаётся значение CA, так что обратные переходы (returns) по-прежнему работают.

Аналогичным образом, поскольку Y используется в ОЗУ в качестве индекса, всего 16 из 64 тетрад TMS1000 могут получить адрес из одного только Y. Двухбитный X служит регистром страниц ОЗУ и выбирает «file». В TMS1100 ОЗУ также дублируется, но здесь всё решается применением трёхбитного X вместо двухбитного и соответствующим изменением соответствующей инструкции LDX. Возможный недостаток конструкции состоит в том, что Y может индексировать R-выходы только при незаданном третьем бите, поэтому инструкция COMX были изменена так, чтобы менять только значение нового бита, а не дополнять весь регистр. (Значения Y от 11 до 15 задают значения R-выходов только в расширенных версиях микросхем TMS1200 и TMS1300, где таких выходов 16, а не 11).

4-битный сумматор на снимке кристалла не дублирует функцию компаратора, и на выходе сумматора может быть либо A, либо Y, либо ни одно из этих значений (небольшая полоска схемы под сумматором осуществляет выбор адреса). Перенос (carry) или заимствование (borrow), если оно реализовано, переходит к S. Арифметическое логическое устройство выполняет только операции сложения и вычитания, побитовых логических инструкций нет. С другой стороны, инструкции SBIT и RBIT могут задать быты 0 или 1 на любой позиции любой тетрады, индексируемой при помощи X и Y, а TBIT1 могут проверить значение (бита по S), поэтому любая логическая операция можно реализовать (довольно трудоёмким) способом обхода всех четырёх битов и установки соответствующих значений.

Единственный регистр, который может записывать в регистр O-вывода, — это накопительный регистр, но так как он всего четырёхбитный, пятый бит приходится брать из S. Есть инструкции memory-to-memory и даже constant-to-memory (TCMIY), но из всех регистров только накопительный может загружать и хранить данные из памяти, только он может суммировать и вычитать значения из памяти, только он может получить сигналы с K-входов (хотя вы также можете протестировать их как группу), только его значения можно сравнивать (со значениями памяти или Y, результат с S), и только он может суммировать или вычитать значение больше единицы.

Зная всё это, рассмотрим те программы, которые мы подчистую переписали из руководства программиста. Первая из них производит сдвиг на шесть тетрад в памяти, где нулевая позиция соответствует цифре наименьшего значащего разряда, как при вводе новой цифры на калькуляторе.

lshft   cla     ; clear A ldata   tcy 0   ; transfer constant 0 to y l1      xma     ; exchange memory indexed by Y and the accumulator         iyc     ; y++, carry to S         ynec 7  ; s = (y!=7)         br l1   ; branch if true to l1          retn    ; if this were a call

При вводе значения ldata накопительный регистр вместо нуля приобретает значение цифры наименьшего значащего разряда.

  • А вот программа сложения двух банков по шесть тетрад. Поскольку эта программа предназначалась для калькулятора, она выполняет сложение в двоично-десятичном представлении, рассматривая каждую тетраду как цифру. X задаёт адрес назначения суммы m, переворачивая значение старшего бита. Таким образом, в TMS1100 при X, равном 0, это означает, что нужно цифры в файле 0 прибавить к цифрам в файле 4 и хранить их в файле 0 и так далее. В версии 1100 нет инструкции ALEC (A меньше константы [похоже, речь идёт о less or equal — меньше либо равно]), которая присутствовала в TMS1000. Это не позволяет напрямую проверить факт вхождения нашей цифры в диапазон, для этого нужны дополнительные ухищрения.

a040    tcy 0         cla ad1     comx    ; flip X bit 3 (note: on TMS1000 this flips both bits of X)         amaac   ; add m(x,y) to accumulator, carry to S, result to accumulator         comx         amaac         br gt15 ; branch if carry set (greater than 15)         a6aac   ; add six to digit. 10 becomes 16, which is zero, etc. (carry to S)         br gt9  ; greater than 10         a10aac  ; add ten to digit to fix a digit less than 9         tamza   ; transfer accumulator to memory indexed by Y and clear accumulator         br incy gt15    a6aac   ; 16 becomes 6, 17 becomes 7, etc. gt9     tamza         iac     ; increment accumulator, inverse of carry to S incy    iyc         ynec 7         br ad1         retn

Последовательность инструкций AnAAC представляет собой одну группу микрокоманд с множеством мнемоник, но с кодированием нестандартных констант. CLA и IAC также взаимосвязаны.

И вот, наконец, перед нами программа, которая выдаёт шесть тетрад в качестве сегментов на O-выходы, подтягивая каждый R-выход к нижнему логическому значению от 6 слева до 0 справа, чтобы дисплей знал, какая цифра отображается, в цикле до тех пор, пока на К-входах не сработает какая-либо клавиша, после чего система заблокирует ложные повторные нажатия этой клавиши. При этом предполагается, что семисегментное преобразование цифр при выводе на светодиоды происходит на выходной ПЛМ.

disp    tcy 7 dis1    dyn     ; y--, inverse of borrow to S         tma         iyc         rstr    ; R(Y)=0         dyn         tdo     ; O=A         setr    ; R(Y)=1         knez    ; any K bits set?         br exit ; yup         ynec 15 ; s = (y!=15) which would mean it underflowed         br dis1 ; continue digits         br disp ; start over from the left exit    tcy 15         tya     ; transfer Y to A; can't load non-zero constants to A directly delay   dan     ; decrement A, inverse of borrow to S         br delay; branch as long as we don't borrow         dyn         br delay         ; total delay 544 cycles

Если вам действительно нужно значение K, вы можете выбрать его до задержки с помощью TKA и заранее спрятать накопительный регистр где-нибудь в памяти.

Дополнительное ОЗУ также может управляться R-выходами. Например, для микросхемы на 256×4 бит ОЗУ микроконтроллер может поместить адрес на R(0) — R(7), Chip Select на R(8) и Read/Write на R(9), выдать данные для записи на младшую тетраду O-выхода и прочитать данные с K-входов. Система мультиплексирования может сделать возможным применение этих линий для других целей, хотя мы приближаемся к моменту, где лучше подойдёт более мощный процессор. К счастью для Mattel, небольшого объёма встроенной ОЗУ оказалось более чем достаточно для управления состоянием игры, условиями игроков и одним особо разъярённым драконом.

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

И, да, прежде чем положить игру обратно в коробку, сыграем в неё, чтобы лучше понять, как много всего достигнуто такими скромными средствами. Отведай-ка моей булавы, литой четырёхбитный дракон с компьютерным управлением!


ссылка на оригинал статьи https://habr.com/ru/company/skillfactory/blog/719624/

Как экспертиза в области мониторинга событий ИБ помогает создавать качественные продукты. Часть 2

Друзья, всем привет. Недавно мы анонсировали серию публикаций о детектировании атак (attack detection) и тех вызовах, c которыми сталкиваются пользователи средств защиты. В первой статье этого цикла материалов мы уже раскрыли секреты attack detection в привязке к SIEM-решениям (системам мониторинга событий ИБ и выявления инцидентов, security information and event management) и поделились лайфхаками, как облегчить работу операторов и автоматизировать часть рутинных задач. В этом материале — подробнее о том, как механизм построения цепочек запускаемых процессов в MaxPatrol SIEM помогает выявлять атакующих в сети.

Любая PT Expert Security Center (PT ESC), разработать механизм, автоматизирующий построение цепочек запускаемых процессов на основе событий безопасности Windows EID 4688, Sysmon EID 1 и событий подсистемы аудита Linux (auditd). Мы придумали механизм, обогащающий любое скоррелированное событие, в котором есть информация о процессе, его полной цепочкой и записывающий данную информацию в отдельное поле таксономии.

Рис. 1. Пример нормализованного события запуска процессов Sysmon EID 1
Рис. 1. Пример нормализованного события запуска процессов Sysmon EID 1
Рис. 2. Пример нормализованного события подсистемы аудита Linux (auditd)
Рис. 2. Пример нормализованного события подсистемы аудита Linux (auditd)

Это решение позволило не только разгрузить операторов SOC за счет автоматизации задач по «раскручиванию» цепочек процессов, но и расширить возможности продукта: новое поле таксономии с данными о цепочках процессов в некоторых случаях облегчает написание правил корреляции, используется для тут (см. рис. 3)). При активации механизма в MaxPatrol SIEM цепочки процессов строятся независимо от данных EDR или дополнительных расширений в режиме реального времени и без участия человека; с этими данными можно работать как с любым другим полем таксономии. Об этом поговорим дальше.

Рис. 3. Пример расширения для браузера, строящего дерево процессов по событиям из базы данных по запросу пользователя
Рис. 3. Пример расширения для браузера, строящего дерево процессов по событиям из базы данных по запросу пользователя

Анализ атомарных сработок правил корреляции

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

Наличие в карточке события данных о цепочке процессов в разы сокращает время, необходимое операторам на понимание контекста сработки даже путем визуального анализа данных. Любая сработка правила корреляции в MaxPatrol SIEM, имеющая данные о процессе (имя процесса и его PID), будет обогащаться цепочкой запускаемых процессов независимо от типа события.

Рассмотрим несколько практических примеров обнаружения различных TTP, относящихся к данному разделу.

1. Discovery. Account Discovery. Пример сработки правила корреляции на рекогносцировку активности пользователей через взломанный сервер Exchange.

Рис. 4. Сработка правила корреляции на рекогносцировку активности пользователей с механизмом построения цепочек запускаемых процессов
Рис. 4. Сработка правила корреляции на рекогносцировку активности пользователей с механизмом построения цепочек запускаемых процессов

2. Discovery. Remote System Discovery. Пример сработки правила корреляции на рекогносцировку контроллера домена, основанного на событии запуска процесса без данных о цепочке процессов, и та же сработка правила корреляции с данными о цепочке процессов.

Рис. 5. Сработка правила корреляции на рекогносцировку контроллера домена без механизма построения цепочек запускаемых процессов
Рис. 5. Сработка правила корреляции на рекогносцировку контроллера домена без механизма построения цепочек запускаемых процессов
Рис. 6. Сработка правила корреляции на рекогносцировку контроллера домена с механизмом построения цепочек запускаемых процессов
Рис. 6. Сработка правила корреляции на рекогносцировку контроллера домена с механизмом построения цепочек запускаемых процессов

3. Discovery. System Network Configuration Discovery. Пример сработки правила корреляции на рекогносцировку конфигурации сетевого подключения в операционной системе Linux с механизмом построения цепочек запускаемых процессов.

Рис. 7. Сработка правила корреляции на рекогносцировку конфигурации сетевого адаптера с механизмом построения цепочек запускаемых процессов
Рис. 7. Сработка правила корреляции на рекогносцировку конфигурации сетевого адаптера с механизмом построения цепочек запускаемых процессов

4. Discovery. System Network Connections Discovery. Пример сработки правила корреляции после запуска пользователем вредоносного офисного документа.

Рис. 8. Сработка правила корреляции на рекогносцировку сетевых подключений с механизмом построения цепочек запускаемых процессов
Рис. 8. Сработка правила корреляции на рекогносцировку сетевых подключений с механизмом построения цепочек запускаемых процессов

Даже квалифицированному сотруднику потребуется немало времени для нахождения вредоносного процесса, который инициировал последующую активность, и сработки правил корреляции. Однако, имея в карточке события поля с цепочкой процессов, относящиеся к конкретной сработке, оператор MaxPatrol SIEM освободит себя от необходимости выяснять это.

Написание правил корреляции на основе данных о цепочке процесса

Для того чтобы учесть в корреляции цепочку из нескольких процессов, необходимо писать минимум два правила корреляции или использовать табличный список для записи временных данных. Благодаря наличию поля таксономии с данными о цепочке процесса, оператору не нужно будет писать дополнительные правила корреляции или использовать дополнительные табличные списки.

Рис. 9. Пример фильтра события в правиле корреляции, обнаруживающего аномальные цепочки запуска процессов, родителем которых является агент антивируса Kaspersky klnagent
Рис. 9. Пример фильтра события в правиле корреляции, обнаруживающего аномальные цепочки запуска процессов, родителем которых является агент антивируса Kaspersky klnagent
Рис. 10. Пример фильтра события в правиле корреляции, обнаруживающего цепочку запуска процессов с утилитами веб-сервера
Рис. 10. Пример фильтра события в правиле корреляции, обнаруживающего цепочку запуска процессов с утилитами веб-сервера

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

Особенности механизма построения цепочек процессов

Как будет выглядеть цепочка процесса, когда пользователем был запущен файл, загруженный через мессенджер или браузер? И как она будет выглядеть до процесса, если злоумышленнику удастся мигрировать в другой процесс и продолжить свою активность в нем?

При анализе сработок правил корреляции бывают случаи, когда с первого взгляда оператор может посчитать сработку false positive, но активность является нелегитимной. Рассмотрим два сценария.

Первый сценарий. Пользователю пришло фишинговое письмо, он перешел по ссылке, скачал и запустил вредоносный файл — у злоумышленника появилась возможность выполнять команды на зараженном компьютере. В случае, если какое-либо правило корреляции сработает на последующую активность данного вредоносного процесса, то цепочка до процесса будет начинаться от процесса explorer.exe. Однако разработанный нами механизм предусматривает такой сценарий и продолжает выстраивать цепочку процесса с момента загрузки файла из браузера.

Рис. 11. Пример построения цепочки процессов
Рис. 11. Пример построения цепочки процессов

Второй сценарий. Часто после успешного «пробива» узла злоумышленнику необходимо мигрировать в другой процесс для сохранения доступа на скомпрометированном компьютере или для сокрытия следов активности за счет работы внутри легитимного процесса. В случае если такая ситуация произошла, а после этого сработало правило на какую-либо последующую активность, то в цепочке процессов будет формироваться цепочка до процесса, в который произошла миграция. Разработанный нами механизм предусматривает и такие кейсы и строит всю цепочку процессов до момента миграции.

Рис. 12. Отображение процесса, в который мигрировал злоумышленник (в фигурных скобках)
Рис. 12. Отображение процесса, в который мигрировал злоумышленник (в фигурных скобках)

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

«Тюнинг» сработок правил корреляции

Данные о цепочке процесса можно использовать при осуществлении «тюнинга» системы — вайтлистинга. Иногда целесообразнее добавить в исключение цепочку процессов, вместо того чтобы писать регулярные выражения. А в случае, если цепочка процессов является вредоносной, ее можно добавить в блэклист. Подробнее о механизмах работы с исключениями в MaxPatrol SIEM мы рассказали тут и тут.

Рис. 13. Пример шаблона исключений для данных с цепочкой процесса
Рис. 13. Пример шаблона исключений для данных с цепочкой процесса

Надеюсь, что данный материал был полезен и вы найдете добавленному в продукт механизму свое применение. Мы будем продолжать знакомить вас с историями о том, как наша экспертиза помогает делать продукты еще более удобными для специалистов по ИБ. Так что следите за выходом новых материалов 😊

До новых встреч!


Автор: Алексей Потапов, эксперт отдела обнаружения атак, PT Expert Security Center


ссылка на оригинал статьи https://habr.com/ru/company/pt/blog/719438/