Сегодня мы будем анализировать бинарники на пару с CPU профилями, чтобы создать на их основе расширенные профили исполнения. Эти дополненные профили мы сможем использовать для оценки времени, которое программа тратит на проверки выхода за границу массивов и слайсов.
Разбор фрагментов кода из загадочной книги, которая содержит только ассемблерный листинг и никаких комментариев. Часть 1
Удаление Witelist ноутбука HP Pavilion dv6-2135er. Реверс-инжиниринг и модификация дампа bios.
Недавно в процессе выполнения учебного задания мне потребовалось реализовать метод конечных разностей для нахождения приближённого решения краевой задачи. По сути, я впервые столкнулся с вычислениями с плавающей точкой и не мог не попробовать запустить свою программу на Эльбрусе, зная о его больших возможностях и заточенности под вычисления такого рода. Хотите удивиться? Отправляйтесь со мной в увлекательное путешествие!
Привет, Хаброжители! Обратите внимание на большую распродажу в честь Старого Нового года.
Когда виртуальная машина Java компилирует ваш исходный код Java в машинный, одна из задач, которые она должна при этом выполнить – решить, где хранить локальные переменные Java и другие подобные временные значения. В вашей машине отсутствует концепция локальных переменных, поэтому на этапе компиляции необходимо определиться, какое место в памяти стека (какой машинный регистр) будет использоваться для хранения каждой переменной. Эта операция называется «выделение регистров». Может показаться, что выделение регистров – сложная абстрактная теоретическая тема, но в этом коротком посте я покажу, как сначала соотнести исходный код Java с теорией, потом понять, как его видит компилятор, а потом – показать результирующий машинный код. В данном случае моя цель – продемонстрировать, что все эти концепции очень легко опробовать на практике с реальным компилятором.
Люди часто думают, что код на ассемблере читается не просто плохо, а очень плохо. Но я думаю, что это совершенно не так.
Я всегда считал, что читаемость кода на совести программистов и язык здесь совершенно не причём.
Так вот, когда работал над одним из своих проектов, мне понадобился алгоритм для поиска следующего или предыдущего листа дерева. Алгоритм тривиальный, но реализация получилась такой компактной и простой, что решил опубликовать её в качестве иллюстрации того, что на ассемблере можно (и нужно) писать удобочитаемый код.
Честно говоря, я сомневаюсь, что на языке высокого уровня можно написать это более компактно и понятно.
Но возможно я ошибаюсь. Увидим далее в статье.
Сразу пишите в комментариях, что вас больше всего бесит в клавиатурах для PC. Внесу пожелания в техзадание, если это будет возможно. Какой вы видите идеальную клавиатуру для ПК?
Эта история случилась в 2015 году. Тогда я написал статью для своего сайта на болгарском языке. А в прошлом году, я решил подтянуть свои знания в русском языке. И сделал этот перевод в качестве упражнения.
Ну и решил опубликовать. Конечно осовременил и укомплектовал картинками.
Надеюсь, эта почти детективная история вам понравится.
Рассказ о том, как работает Tiobe index, как это связано с ассемблером и о моей маленькой роли во всем этом.
После выпуска System Beeps, музыкального альбома для PC Speaker, я не планировал возвращаться к псевдомногоголосой одноканальной музыке в формате подобных крупных самостоятельных релизов, считая тему достаточно раскрытой. Это, конечно, не означало отказа от более утилитарного применения подобных наработок при подходящем случае, например, в ретро-игровых или демосценовых проектах для старых компьютеров. Осенью прошлого года на горизонте появился очередной проект подобного плана от автора популярного Youtube-канала The 8-bit Guy, Дэвида Мюррея — игра Attack of the PETSCII Robots для линейки 8-битных компьютеров Commodore, включая PET, VIC-20 и C64. Я уже сотрудничал с Дэвидом на его предыдущем проекте, игре Planet X3 для MS-DOS. Новая затея как нельзя лучше соответствовала моему интересу к персоналкам до-графической эпохи и большому опыту как в области минималистичного компьютерного звука, так и программировании на ассемблере для процессора 6502, поэтому я срочно вписался в работу над проектом, надеясь на этот раз помимо написания звукового кода поучаствовать и в сочинении музыки.
В рабочем процессе возникали разнообразные проблемы, плавно перетёкшие в небольшой производственный ад (скандалы, интриги и расследования можно найти в серии постов в моём Patreon), в результате чего мой код и звуки были использованы только в версии для VIC-20, а музыку к остальным версиям игры написали другие композиторы. Но у меня оставались наработки в виде рабочего кода для PET и набросков композиций. Было жалко отправлять их в стол, ведь релизы для этой платформы — явление крайне редкое, и нового шанса задействовать то, что уже было сделано, пришлось бы ждать долго. Поэтому, с одобрения Дэвида, я принял решение дописать наброски до полноценных треков и выпустить свой альтернативный саундтрек в виде небольшого альбома под названием Faulty Robots, как в виде аудио, так и в формате самостоятельной программы для PET.
Я не буду делать длинное вступление. Один знакомый хакер однажды сказал, что 10 строк кода могут быть понятнее и интереснее, чем 1000 слов объяснений. Все эти примеры написаны на ассемблере для архитектуры Z80 и запускаются на ретро-компьютере ZX Spectrum 48k.
Мы уже несколько лет преподаем разработку компонентов учебной операционной системы xv6, и хотим поделиться своим опытом. Этот курс прошли уже около 600 студентов. Если вас заинтересует эта статья, то вы можете ознакомиться с нашим курсом.
После базовых курсов вроде операционных систем часто студенты выходят без реальных практических знаний. Лучше всего можно понять работу операционной системы, написав её самому. Но так как этот процесс может занять не один семестр, в рамках учебного курса можно ограничиться разработкой только ключевых компонентов. Для этого мы используем учебную операционную систему xv6, про которую расскажем ниже, так как она значительно проще Linux или других пользовательских ОС.
Основной задачей было уменьшение размера программы, т.к. использовали микроконтроллер с небольшим объемом памяти, а функциональность изделия должна быть большой. По этому появилась идея использовать анализатор кода, поиск в интернете ничего не дал, по этому пришлось делать самостоятельно.
Решил поделиться идеями, так как думаю что может кто-то напишет более приличную программу для анализа программы на ассемблере 8051.
В этой статье опишу основные этапы получившегося анализатора. Часть этих этапов можно использовать для анализа программ написанных на других языках.
Этап 1. Сначала необходимо преобразовать исходный текст программы к максимально простому виду. С кодом программы из которого удалили все лишнее удобнее работать.
Этап 2. Создал таблицу, в которую занес строки исходной программы, тип команды, тип операндов, адрес в памяти и т.д.
Оптимизированные по размеру уже известные алгоритмы CRC, Gnome Sort etc...
Фанатам ассемблера посвящается.
Всем привет! Решил подключить матрицу светодиодов 8х8 и вывести на неё решение задачи о 8 ферзях. [Описание см. на Википедии]
Процессор
В качестве процессора я выбрал компактный и шустрый процессор attiny85. Программа будет написана на ассемблере. С небольшими настройками программа должна работать на любом другом процессоре AVR: attiny и atmega.
Дисплей
В качестве дисплея используем матрицу светодиодов, которая состоит из 8 вертикальных рядов и 8 горизонтальных строк со светодиодами.
Прим. Wunder Fund: в жизни каждого человека случается момент, когда ему приходиться позаниматься реверс-инжинирингом. В статье вы найдёте базовые особенности работы с ассемблером, а также прочитаете увлекательную историю господина, который решил написать Питон-библиотеку на ассемблере и многому научился на своём пути.
Иногда, чтобы полностью разобраться с тем, как что-то устроено, нужно это сначала разобрать, а потом собрать. Уверен, многие из тех, кто это читают, в детстве часто поступали именно так. Это были дети, которые хватались за отвёртку для того, чтобы узнать, что находится внутри у чего-то такого, что им интересно. Разбирать что-то — это невероятно увлекательно, но чтобы снова собрать то, что было разобрано, нужны совсем другие навыки.
Нечто, выглядящее для стороннего наблюдателя как работающая программная система, таит внутри себя хитросплетения паттернов проектирования, патчей и «костылей». Программисты привыкли работать на низких уровнях систем, привыкли возиться с их неказистыми «внутренностями» для того, чтобы заставить эти системы выполнять простые инструкции.
Эксперимент, о котором я хочу рассказать, пронизан тем же духом. Мне хотелось узнать о том, смогу ли я написать расширение для CPython на чистом ассемблере.
Зачем мне это? Дело в том, что после того, как я дописал книгу CPython Internals, разработка на ассемблере всё ещё была для меня чем-то весьма таинственным. Я начал изучать ассемблер для x86-64 по этой книге, понял какие-то базовые вещи, но не мог связать их со знакомыми мне высокоуровневыми языками.
Вот некоторые вопросы, ответы на которые мне хотелось найти:
— Почему расширения для CPython надо писать на Python или на C?
— Если C-расширения компилируются в общие библиотеки, то что такого особенного в этих библиотеках? Что позволяет загружать их из Python?
— Как воспользоваться ABI между CPython и C, чтобы суметь расширять возможности CPython, пользуясь другими языками?
До того как заняться реверс-инжинирингом, исполняемые файлы казались мне черной магией. Я всегда интересовался, как все работает под капотом, как двоичный код представлен внутри .exe файлов, и насколько сложно модифицировать “исполняемый код” без доступа к исходникам.
Но одним из главных препятствий был язык ассемблера, отпугивающий большинство людей от изучения этой области.
Это главная причина, по которой я задумался о написании этой статьи, содержащей только самые важные вещи, с которыми чаще всего сталкиваются в реверс-инжиниринге, хотя она и упускает некоторые детали для краткости, предполагая, что у читателя имеются навыки поиска определений и ответов в Интернете и, что более важно, придумывания примеров / идей / проектов для практики.
