Что если защита от копирования вообще не содержит ни одного условного перехода? Ретро-разбор библиотеки 2009 года, где вместо if (key == valid) используется вычисление адреса следующей функции, любая ошибка в данных уводит процессор в никуда.

Классический взломщик ищет в дизассемблере инструкции JZ/JNZ и инвертирует их ("Magic Jump"). Здесь этот приём не работает: нет точки принятия решения, нет и цели для патча. Вместо этого серийный номер диска, CRC32 исполняемого файла и системная дата складываются в единственно верный адрес перехода. Чуть изменил данные - получил Access Violation в случайном месте памяти.

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

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

• Автоматическая синхронизация буфера обмена далеко не безопасна, можно случайно «засветить» чувствительные данные в другой системе.

Возникла необходимость организовать трафик к внешнему сервису из сегмента с ограничением на исходящие соединения. Этот внешний сервис использовал одновременно множество tcp/udp сокетов. При беглом обзоре существующих утилит не обнаружил готовое решение инкапсуляции множества сокетов с поддержкой «обратного» соединения.