— Папа, я бежал за троллейбусом и сэкономил пять копеек!
— Сынок, бежал бы за такси — сэкономил бы пять рублей!


Сегодня я хочу рассказать вам, как сэкономить 10 тысяч долларов. А заодно, что гораздо менее интересно – научить перехватывать вызовы Win32 API функций, и не только. Хотя, в первую очередь – конечно, именно их.

Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

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

Введение

Shed Skin — это экспериментальный транслятор из Python в C++, разработанный для повышения скорости выполнения программ на Python с интенсивными вычислениями. Он преобразует программы, написанные на ограниченном подмножестве языка Python, в C++. Код C++ можно скомпилировать в исполняемый код, который может быть как отдельной программой, так и модулем расширения, легко импортируемым и используемым в обычной программе на Python.

Питон изумителен.

Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).

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

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

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

Все начинается с понимания того, чем на самом деле является “Питон”.

Как всё начиналось

Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.

Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.

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

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

Начать, видимо, следует с того, что речь пойдет об интерпретаторе CPython версии 2.7.x (примеры проверялись на версии 2.7.3).

На официальном сайте имеются описания инструкции import и модулей в Python:

• docs.python.org/2/reference/simple_stmts.html#import
• docs.python.org/2/tutorial/modules.html

Из них следует, что в Python имеются пакеты (package), модули (module) и имена, определенные в модулях (names). Также следует отметить, что в некоторых частях документации модули называются подмодулями (submodule), если они размещены внутри пакета.

В языке Python инструкция import позволяет импортировать пакеты, модули и имена в пространство имен, в котором инструкция import выполняется. При это существует две интересные особенности:

1. Из синтаксиса инструкции import не всегда явно следует, что именно должно быть импортированно: пакет, модуль или имя
2. Синтаксисом инструкции import невозможно явно указать, что путь к модулю является абсолютным путем (хотя явно указать, что путь является относительным можно, а также возможно изменение семантики инструкции, в части использования абсолютного пути по умолчанию, см. www.python.org/dev/peps/pep-0328 )

Из этих двух особенностей следуют такие неоднозначности для записи import abcd:

1. Импортировать ПАКЕТ abcd, либо импортировать МОДУЛЬ abcd
2. Импортировать пакет/модуль abcd из ТЕКУЩЕГО ПАКЕТА (из пакета того модуля, в котором исполняется import abcd), либо ИЗ ПАКЕТА в соответствии с перечнем каталогов, указанных в sys.path

Еще примеры неоднозначностей:

• from abcd import defg: (импортировать модуль defg из пакета abcd, либо импортировать пакет defg из пакета abcd, либо импортировать имя defg из пакета abcd, либо импортировать имя defg из модуля abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)
• import abcd.defg: (импортировать пакет defg из пакета abcd, импортировать модуль defg из пакета abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)

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

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

Сегодня я предлагаю перейти к практике и покажу на примерах способы ручного профилирования (и даже «метод пристального взгляда». Будут так же рассмотрены инструменты для статистического профилирования.

В этой главе сказа про дружбу C++ и Python будет на удивление мало использования Boost.Python. Передача исключений туда и обратно является по сути слабым местом данной библиотеки. Будем обходиться родным API языка Python, а где это возможно использовать Boost.Python.
Тем не менее Boost.Python создаёт окружение, в котором исключения из C++ попадают в Python в виде стандартного RuntimeError, а обратно из Python генерируется исключение C++ типа error_already_set, что означает «тебе что-то прилетело, сходи сам почитай что там». И вот здесь нам как раз будет не лишним использовать C-API языка Python, чтобы вычитать необходимую информацию об исключении и преобразовать в соответствующий класс сообразно логике приложения.
К чему такие сложности? — Дело в том, что в Python, в отличие от C++, кроме текста исключения и его типа приходит ещё и traceback — стек до места возникновения исключения. Давайте немного расширим стандартный std::exception дополнительным параметром для этого stacktrace, а заодно напишем конвертер исключений туда и обратно из классов C++ в классы исключений Python.

     Знание структуры машинных команд уже много лет не является обязательным, для того, чтобы человек мог назвать себя программистом. Естественно так было не всегда. До появления первых ассемблеров программирование осуществлялось непосредственно в машинном коде. Каторжная работа, сопряженная с большим количеством ошибок. Современные ассемблеры позволяют (в разумной степени) абстрагироваться от железа, метода кодирования команд. Что уж говорить о компиляторах высокоуровневых языков. Они поражают сложностью своей реализации и той простотой, с которой программисту позволяется преобразовывать исходный код в последовательность машинных команд (причем преобразовывать, в достаточной степени, оптимально). От программиста требуется лишь знание любимого языка/ IDE. Знание того, во что преобразует компилятор исходный листинг вовсе не обязательно.
Тем же, кому интересно взглянуть на краткое описание структуры кодирования машинных команд, пример реализации и исходный код дизассемблера для x86 архитектуры, добро пожаловать.

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

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

Задача: «Осушить» гараж.

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

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

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Вы властны над своим разумом, но не над внешними событиями. Когда вы поймёте это, вы обретёте силу.
Марк Аврелий, «Медитации».

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

Обработчики событий

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

Недавно мы писали про новую опасную уязвимость CVE-2014-6332 в Windows, которая присутствовала (MS14-064) в библиотеке OleAut32.dll, а точнее, в функции OleAut32!SafeArrayRedim. Эта функция используется движком VBScript (vbscript.dll) для run-time изменения размера массива в формате SAFEARRAY. В самой SafeArrayRedim содержалась уязвимость, которая позволяла внутри функции модифицировать поле размера массива, а потом возвращать результат неуспешности операции, что приводило к увеличению размера буфера с точки зрения самой структуры. Подробнее см. здесь.



В силу того, что эксплойт для этой уязвимости (Windows OLE Automation Array Remote Code Execution Vulnerability), фактически, может оперировать памятью напрямую, из-за порчи структуры заголовка буфера функцией ОС, ему не нужно прибегать к операциям срабатывания уязвимости типа use-after-free, вся эксплуатация сводится к последовательному исполнению нескольких функций, которые помогают запустить процесс из функции VBScript в обход DEP & ASLR.

Что в первую очередь сделает iOS разработчик, если перед ним встанет задача спрятать пользовательские данные от любопытных глаз? Конечно же, встроит экран парольной защиты. Особо хитрый разработчик даже не будет хранить установленный пользователем пароль в NSUserDefaults, а аккуратно спрячет его в связку ключей — в этом случае приложение в глазах как его, так и заказчика, сразу же перемещается в разряд «сверхзащищенных».
Мы не будем углубляться в описание опасностей хранения ключа в открытом доступе — ведь есть гораздо более интересный способ обхода такой защиты.

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

От переводчика: мы в компании Энтерра очень любим алгоритмы компьютерного зрения. Работаем чаще всего с OpenCv. Время от времени нам пишут разные разработчики с вопросами: «А как лучше начать работать с OpenCv?» или «Какую интересную задачу можно просто решить с помощью OpenCv?» В связи с чем мы решили перевести очень хорошую статью, которая будет полезна всем, кто интересуется компьютерным зрением.



Черная Пятница близко.

Толпы злых покупателей. Рой одинаковых теток среднего возраста, готовых сожрать практически всё, что угодно, в ближайшем супермаркете — главное, что со скидкой 75%. Они выстроятся в очереди перед дверьми магазинов в полночь Дня благодарения. Они будут ломиться внутрь, стучать в запертые двери кулаками и головами, пока не сплющат друг друга и не разобьют руки в кровь, став похожими на зомби из «28 дней спустя». Но вместо человеческой плоти, они жаждут удовлетворить инстинкт покупателя. Их боевые кличи о скидках и распродажах достигают небес. А их громовая поступь способна привести к землетрясению на Великой Равнине.

Естественно, от СМИ помощи не жди — они будут смаковать каждую подробность. От обмороженных семейств, ночевавших в палатке на морозе, до старой леди, растоптанной охотниками за скидкой в момент, когда открылись двери. Что-то похожее случилось с галлимимусом в «Парке Юрского периода». А она просто хотела купить Halo для девятилетнего внука Тимми, чьи родители забыли это сделать в прошлом году. В Wal-Mart. Во время Черной Пятницы.

И я обязан спросить: весь этот хаос и бедлам стоят того?

Чёрт возьми, нет!

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

Просто представьте, как глупо вы будете выглядеть, стоя в очереди в ожидании свободной кассы – только для того, чтобы после сканирования штрихкода последнего сезона «Игры Престолов» выяснить, что в Target его можно купить на 5 долларов дешевле?

Собственно, далее я покажу, как можно обнаружить штрихкод на изображении, используя только Python и OpenCV.

Компания IBM объявила о том, что организации всех масштабов, от стартапов до огромных корпораций, переходят на платформу IBM Bluemix для быстрой и качественной разработки программного обеспечения.

Мы уже писали о машинном обучении как сервисе в облаке Microsoft Azure здесь. И, совсем недавно, Microsoft решили открыть (как ранее с Azure Web Sites) возможность бесплатного тестирования этого тестирования без аккаунта Microsoft Azure, без кредитной карты. Отличная возможность посмотреть, что умеет Machine Learning в облаке.

Недавно мы запустили сервис ABBYY Cloud OCR SDK, работающий на облаке Windows Azure и попутно набрали 100500 опыта. Например, узнали, что многие используют слово «облако» и слышали, что «облака – это модно», но очень немногие понимают, что такое облако и главное – зачем делать сервис именно в облаке. Слово «облако» повсеместно используется и, похоже, начало обрастать городскими легендами.

Посмотрите, например, вот это видео:



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

Рассмотрим подробно, что такое публичное облако, зачем может иметь смысл использовать его для работы ПО и правда ли, что «скоро все будет в облаках».

Проект Mutiplo я заметил давно, ещё на этапе когда они успешно завершили кикстартер кампанию — было это в октябре 2012 года. Проект выстрелил успешно — почти 10-кратное превышение заявленной суммы! Из заявленных $15,000 было собрано $132,022 и более 700 вкладчиков.

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

Оригинальным было конструктивное решение — они придумали свои механизмы крепления, и так же большим плюсом было то что проект полностью open-source и open-hardware проект — то есть все чертежи конструктивных элементов должны были быть выложены в открытый доступ — чтобы любой желающий мог сам нарезать на лазерном ЧПУ или напечатать на 3d-принтере. И так же схемы всей используемой электроники — выложены в открытый доступ.

В том далеком 2012 году, я лишь интересовался робототехникой, и мне интересно было, что получится из этого проекта. В следующем году мы организовали хакспейс в Екатеринбурге — MakeItLab, и конечно же набор Mutiplo был в числе тех, что мы хотели посмотреть вживую, и недавно мы заказали несколько наборов.