Assembler *

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

В одном из моих докладов по ассемблеру я показал список из 20 самых часто исполняемых команд на среднем десктопе x86 с Linux. Разумеется, в этом списке были привычные  mov, add, lea, sub, jmp, call и так далее; неожиданным стало включение в него xor — «eXclusive OR». В эпоху, когда я занимался хакингом на 6502, наличие XOR было почти абсолютно точным указанием на то, что найдена часть кода, связанная с шифрованием, или какая-то подпрограмма обработки спрайтов. Поэтому удивительно, что машина с Linux, просто занимающаяся своими делами, выполняет такое количество этих команд.

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

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

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

🧲 Что если общество можно моделировать как игру, а иерархии — это просто баг старого механизма? Я хочу построить симуляцию, которая проверит, возможна ли цивилизация массовых изобретателей.

Кто угодно может пнуть мёртвого льва. Мёртвый лев не рыкнет на наглеца. Мёртвый лев не откусит ему ногу «по самое не хочу», хотя стоило бы. Лев мёртв, и теперь его может пнуть каждый ишак, что конечно же не показывает превосходство ишака над львом. Эта статья будет полна негодования и ненависти. Кровь ещё закончила кипеть от негодования. Но, разумеется, помимо эмоций будут и сухие объективные факты, немножко исследования и расстановка точек над i. В интернете кто-то не прав... опять...

Существует целый ряд инструментов, технологий и вообще вещей, которым по какой-то непонятной вселенской несправедливости не повезло: нашлась масса непонятных людей, которые по какой-то необъяснимой причине начали распускать про эти инструменты/технологии/вещи разные небылицы, идиотские фейки, слухи и прочий порочащий репутацию «компромат». Можно не переживать, если речь идёт о технологии, которая находится «на пике» — у неё будет большое community и правда восторжествует. Совсем другое дело, когда речь идёт о чём-то, что далеко не на пике, чья минута славы в прошлом (возможно даже давно в прошлом) — здесь мёртвый «лев» не может дать сдачи, и что самое обидное, что в какой-то степени «лев» сейчас мёртв отчасти и потому, что ещё при его жизни началось необоснованное распространение всяких бредовых поверий и мифов про него. И сегодня речь пойдёт об одном из таких случаев.

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

Здравствуйте, меня зовут Анна Мелехова. Я старший архитектор в отделе развития архитектуры KasperskyOS. В статье я хочу поделиться практическим опытом системной разработки, которой я занималась сначала в проекте по виртуализации, а теперь в «Лаборатории Касперского», где мы делаем микроядерную операционную систему с повышенными требованиями к безопасности – KasperskyOS. Когда вы работаете в такой среде, быстро понимаете: харденинг – это не красивые галочки в чек-листе, а набор очень конкретных, очень практических решений, которые должны и защищать, и минимально снижать производительность. О них я и расскажу, а в конце дам личный топ самых полезных харденингов, которые бустят security и не снижают performance.

Любительские радиостанции — интересный способ знакомства с работой радиоспектра; что ещё более важно, это встроенные устройства, на которых могут быть установлены странные чипы/прошивки! Мне стало любопытно, насколько просто взломать мою Yaesu FT-70D, поэтому я приступил к расследованию. Единственный ресурс по радиостанциям Yaesu — это пост на Reddit о кастомной прошивке для Yaesu FT1DR.

Пользователь Reddit написал, что если выполнить процесс обновления прошивки через USB, то радиостанция раскрывает микроконтроллер Renesas H8SX, флэш-память которого можно изменить при помощи Renesas SDK. Отличное многообещающее начало, но SDK было не так легко настроить, а я не был даже уверен, сможет ли он сдампить прошивку... поэтому долгое время не брался за него.

Отобрал для вас несколько крайне интересных, но малоизвестных проектов, реализующих работу с XML и JSON. Кроссплатформенных и без зависимостей. На чистом С и ассемблере.

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

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

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

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

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

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

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

Обычная функция в Си передает управление вызывающему коду при помощи оператора return. При этом область стековой памяти, хранящая локальные переменные, больше не принадлежит функции. 

В этой статье я расскажу о микроконтроллерах Sunplus с ядром 6502 которые использовались в популярных в 90-е «тетрисах» Apollo, а также об их эмуляции. Отдельно опишу способ запуска своего кода на этих играх и в частности проигрыватель «Bad Apple!!», крупнопиксельный кадр из которого показан на КПДВ.

Волей случая мне в руки попал ноутбук с гибридным процессором i7-13850HX, у которого есть производительные "Р" и эффективные "Е" ядра, и захотелось разобраться чуть поглубже, процессор довольно любопытный. Под катом мы сделаем несколько несложных замеров производительности.

Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?

Систему управления памятью я разберу, а вот выводы остаются уже за вами.

Когда в 19-летнем возрасте я покупал свой первый компьютер, то я очень сильно хотел купить БК-0010-01. Однако обстоятельства сложились так, что к моменту, когда у меня появилась необходимая сумма, в магазинах БК‑шек не осталось, и вообще ничего не осталось. На полке в «Электронике» лежало только невзрачное нечто с нарисованной клавиатурой и названием «ЛИК».

Здравствуйте, уважаемые читатели Хабра и любители вирусного анализа!

Сегодня хочу поделиться своим дебютным(на Хабре) разбором простенького семпла шелла под Linux.

Начнём.

Откроем в файл в DIE. Семпл для 32-битной UNIX системы, не упакован.

Когда я решил написать программу для простой цифровой фотосъёмки на Apple II, то думал использовать камеры Quicktake. Выбор казался очевидным, потому что это были камеры Apple, способный подключаться к компьютеру через последовательный порт.

Объём задачи немного расширился, когда мне удалось декодировать фотографии Quicktake 100: захотелось научиться декодировать фотографии Quicktake 150 и Quicktake 200. Из-за этого пришлось погрузиться в тему обработки изображений глубже, чем мне хотелось изначально. В этой статье я расскажу о том, как мне удалось заставить работать декодер Quicktake 150 с достаточно приемлемой скоростью на процессоре 6502 с частотой 1 МГц.

Формат Quicktake 150 проприетарный и не имеет документации, однако в проекте dcraw существуют свободные программные декодеры. Они стали моим фундаментом для создания первого декодера на Apple II. К сожалению, они написаны на C, крайне плохо задокументированы и чрезвычайно непонятны (для меня). Сжатие выполняется при помощи кода Хаффмана с переменной длиной (то есть используется битовый сдвиг), а для воссоздания изображения требуется большой объём 16-битных вычислений. Со всем этим 6502 справляется плохо.

Но для начала мне нужно было переписать исходный алгоритм так, чтобы он работал с полосами по 20 пикселей (из-за ограничений памяти). Я написал функциональный декодер, и он работал идеально, но... для декодирования одной фотографии требовалось семьдесят минут.

Этот небольшой этюд служит как бы продолжением статьи "Проценты использования процессора — это ложная метрика". Мы попытаемся копнуть чуть поглубже и более детально разобраться как работает гиперпоточность (или гипертрединг, как его иногда называют).

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

AsmX G3 v29-rev1.0 меняет игру: компилятор, который не только генерирует код, но и пакует его в .deb для Debian/Ubuntu и живёт в AUR с asmx-g3-git, asmx-stable, asmx-official. Проект даёт разработчикам контроль над низкоуровневым кодом и упрощает дистрибуцию приложений. Мощный TAPI и стабильность — всё, чтобы ваш код стал приложением быстрее, чем вы скажете yay -S или paru -S!