![](https://habrastorage.org/webt/9g/kg/wb/9gkgwb96ttlrqlsnqmqgmnjygyu.jpeg)
И да, это снова рубрика Занимательного JavaScript'а: прошу под кат всех неравнодушных.
Пользователь
Сначала небольшая предыстория. В начале 2010-х, я сделал небольшую утилиту-конвертер для BIN файлов эмулятора БК-0010 в WAV файлы. Утилита была написана на Python с целью максимальной переносимости, работала без проблем и я на какое то время забыл о ней. Но в 2016м появился пользователь "неИТшник", понятия не имеющий про Python и как его устанавливать. Он хотел простой исполняемый файл-монолит, который "просто бы работал". Мне его просьба показалась логичной и я решил переработать утилиту в виде набора бинарных исполняемых файлов для основных платформ.
Python и Java не давали такую возможность (если конечно не было желания раздуть утилиту на много десятков мегабайт). Потенциально решение можно было сделать на C/C++, но при таком целевом охвате платформ, сложности с кросс-компиляцией выходили бы за рамки отведенного на задачу времени (а мне надо было поддерживать кросс-сборку для Windows, Linux и MacOS в 64 и 32 битных вариантах). Так что я обратил внимание на набирающий популярность язык Go, который к тому времени уже стал достаточно зрелым и единственным, кто без "плясок с бубном" обеспечивает всю требуемую кросс-компиляцию прямо из коробки (!).
Почему мы вообще хотим писать конкурентный код? Потому что процессоры перестали расти по герцовке и начали расти по ядрам. С каждым годом увеличивается количество ядер процессора, и мы хотим их эффективно утилизировать. Go — тот язык, который создан для этого. В документации так и написано.
Мы берём Go, начинаем писать конкурентный код. Конечно, ожидаем, что легко сможем обуздать мощь каждого ядра нашего процессора. Так ли это?
Меня зовут Артемий. Этот пост — вольная расшифровка моего доклада с GopherCon Russia. Он появился как попытка дать толчок людям, которые хотят разобраться, как писать хороший, конкурентный код.
Видео с конференции GopherCon Russia
gc
. Gccgo имеет встроенную поддержку gdb. Помимо этого обзора Вы можете консультироваться с руководством по GDB.(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8
В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.
В целом эта функция обладает сомнительной прикладной полезностью, поэтому не удивительно, что в Linux готового аналога CreateRemoteThread нет. Однако, мне было интересно, как он может быть реализован. Изучение темы вылилось в неплохое приключение.
Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.
Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.
Данный текст является переводом статьи Тима Карстенса Programming with pcap 2002 года. В русскоязычном интернете не так много информации по PCAP. Перевод сделан в первую очередь для людей, которым интересна тема захвата трафика, но при этом они плохо владеют английским языком. Под катом, собственно, сам перевод.