Какая ассоциация связана у Вас с клавишей F5? Обновление страницы в браузере? Копирование файла из одной директории в другую? Запуск приложения из Visual Studio? А вот авторы notepad.exe подошли к этому вопросу довольно оригинально — по нажатию клавиши F5 происходит добавление текущей даты и времени в место, куда в этот момент указывает курсор. Всё было бы круто, если бы в notepad.exe была такая популярная и вполне естественная для большинства текстовых редакторов фича, как перечитывание содержимого текущего файла, которая, казалось бы, и должна быть назначена на F5 / Ctrl-R или ещё какой-нибудь общепринятый хоткей.

Мы можем ждать, пока её реализуют Microsoft, выбрать другой текстовый редактор (ведь это не единственное ограничение по функционалу стандартного notepad.exe) или… Взять в руки дизассемблер, отладчик и редактор PE-файлов.

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

Добрый день, хабраюзер!

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



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

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

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

На этот раз речь пойдёт об автодополнении путей, которое в большинстве сред и программных продуктов (и cmd.exe не является в данном случае исключением) осуществляется при помощи нажатия клавиш Tab / Shift-Tab. Думаю, никто не станет спорить с тем, что фича это довольно полезная и зачастую экономит до нескольких секунд времени, которое было бы потрачено на ручной ввод полного пути до интересущего пользователя файла или директории. Здорово, что она присутствует и в cmd.exe, однако…

Давайте поэкспериментируем. Запустим cmd.exe (Win-R -> cmd), начнём вводить команду «CD C:/», нажмём Tab, и… Вместо ожидаемых директорий наподобие «Program Files» и «Windows» получим первый по алфавиту объект из %HOMEPATH%, «слепленный» воедино с «C:/» (в моём случае это дало результат в виде «C:/.vim»). Почему? Думаю, те, кому по своему роду деятельности приходилось часто сталкиваться с cmd.exe, уже поняли, в чём тут дело — вместо forward slash'а для корректного автодополнения следовало использовать backslash (кстати, есть и другие исключения в этом плане). Особенно это непривычно для тех, кто большую часть своего времени проводит в других системах (например, *nix-like), где в качестве path separator'а используется как раз прямой слеш, а не обратный. Почему Microsoft решили использовать именно этот символ вместо уже ставшего на тот момент привычным для многих пользователей forward slash'а, объясняется, например, тут. Ну, а нам остаётся либо смириться с этим, либо взять в руки напильник отладчик и заняться исследованием cmd.exe. Если бы мы выбрали первый путь, то никакой статьи и не было, так что Вы уже должны были догадаться, к чему всё идёт.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

Сфера разработки программного обеспечения является одной из тех областей человеческой деятельности, где термин «исторические причины» используется наиболее часто. Оно и понятно — многие «долгоиграющие» проекты наподобие ядер различных операционных систем, браузеров и прочего обросли за время своего существования нехилым арсеналом вещей, менять поведение которых станет далеко не каждый, даже если перфекционист внутри разработчика говорит обратное. Вероятнее всего, большая часть кода была написана программистами, которые уже давно не работают в компании, а даже те, кто ещё связывают свои жизни с данной корпорацией, сомневаются, что остальные компоненты программного комплекса нормально отрерагируют на те или иные изменения. «Нет уж, лучше оставлю, как оно есть».

В качестве примера одной из таких вещей можно назвать cmd.exe. Да-да, это тот самый интерпретатор командной строки, входящий в поставку всех современных (и не очень) операционных систем семейства Windows. Исторических причин у него накопилось изрядное количество — достаточно вспомнить хотя бы то, как необходимо производить вставку и копирование в данный интерпретатор (ради справедливости стоит сказать, что в Windows 10 эту ситуацию наконец исправили, да и приложения наподобие ConEmu здорово в этом помогают). Но речь сегодня пойдёт о другом поведении, которое заствляет задуматься впервые столкнувшегося с cmd.exe человека, казалось бы, там, где этого совсем не требуется.

Как вы знаете, одной из команд, которые воспринимает cmd.exe, является «CD». Официальный хелп по этой команде сообщает следующее:

C:\Users\Nikita.Trophimov>CD /?
Displays the name of or changes the current directory.
[...]

Казалось бы, всё просто. Вызываешь CD без аргумента — в stdout выводится путь до текущей директории, передаёшь другую директорию в качестве аргумента — он сменяет текущую директорию на указанную. Подводные камни тут начинаются в том случае, если пользователь решил сменить директорию одновременно вместе с диском. Например, если вы находитесь в директории «C:\Windows\system32», то команда «CD D:\books» не сделает ровным счётом ничего. На мой взгляд, очевидного для новых пользователей в этом совершенно ничего нет, так что их спасает гугл или официальная документация, которая, кстати, сообщает:

Use the /D switch to change current drive in addition to changing current
directory for a drive.

Разумеется, этот вопрос, равно как и причины возникновения подобного поведения, уже не раз обсуждался в интернете (например, тут), так что останавливаться на подобных вещах мы не будем. Вместо этого мы попробуем отладить cmd.exe, чтобы убрать необходимость явного указания ключа "/D".

Как протекал процесс, и что из этого вышло, читайте под катом.

Перед разработчиками довольно часто встаёт выбор — сделать всё правильно, потратив на решение задачи уйму времени, или сделать так, чтобы работало, не особо вдаваясь в детали того, как именно это получилось. Со стороны заказчика, разумеется, наиболее привлекательной является некая золотая середина, которая в данном случае заключается одновременно и в хорошем понимании программистом выполненного таска, и в как можно меньшем количестве затраченных на него человеко-часов. С разработчиками тоже не всё так однозначно — с одной стороны, понимать, что происходит в своём собственном коде, это вполне естесственное желание (особенно если поддержка данного продукта также будет лежать на его плечах), а с другой стороны, если результаты работы приложения представлены в наглядном виде (графики / звуковые или видео-фрагменты etc), разработка разовая, и отдел тестирования говорит, что всё хорошо, то почему бы не проскроллить оставшуюся часть рабочего времени Хабр, посвятив время себе любимому?

Ближе к делу. В одной из предыдущих статей я уже упоминал о программе под названием «Говорилка». Несмотря на название, сама по себе она ничего не озвучивает, а лишь является связующим звеном между пользователем и речевыми движками, предоставляя более удобный интерфейс и возможность конфигурации. Одним из наиболее популярных в узких кругах движков является «Digalo 2000 text-to-speech engine» (далее — Digalo), ссылку на который можно найти как раз на сайте «Говорилки». Как вы уже, наверное, догадались из тематик моих предыдущих статей, не всё с ним так хорошо, и без багов тут также не обошлось. На этот раз проблема проявилась при озвучивании текста «ааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа». Немного поэкспериментировав, я обнаружил, что при достижении определённого количества «неразрывных» символов Digalo начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

Думаю, что большинство из местных обитателей знакомы с понятием сниффера. Несмотря на то, что конечная цель у них одна и та же (перехват пакетов, соответствующих определённым критериям), достигают они её совершенно разным образом. Какой-то софт слушает указанный сетевой интерфейс (например, Wireshark, где это реализовано при помощи библиотеки Pcap), а какой-то — перехватывает вызовы ответственных за взаимодействие с сетью WinAPI-функций. И у того, и у другого метода есть свои плюсы и минусы, однако если по задаче необходим перехват пакетов от конкретного заранее известного приложения, то второй вариант, как правило, банально удобнее. В этом случае нет нужды узнавать IP-адреса и порты, которые использует данная программа (особенно учитывая тот факт, что их может быть довольно много), и можно просто сказать «я хочу перехватывать все пакеты вот этого приложения». Удобно, не правда ли?

Пожалуй, самым популярным на сегодняшний день сниффером, работающим по принципу перехвата вызовов определённых WinAPI-функций, является WPE Pro. Возможно, многие из вас слышали о нём на различных форумах, посвящённых онлайн-играм, ведь именно для получения преимуществ в различных играх этот сниффер в большинстве случаев и используется. Свою задачу он выполняет прекрасно, однако у него есть один неприятный недостаток — он не умеет работать с 64-битными приложениями. Так уж вышло, что по одной из возникших задач мне как раз понадобилось перехватывать пакеты от 64-битного приложения, и я посмотрел в сторону Wireshark. К сожалению, использовать его в данной ситуации было не очень удобно — исследуемое приложение отправляло данные на разные IP-адреса, каждый раз открывая новый порт. Погуглив немного, я обнаружил, что готовых аналогов WPE Pro с поддержкой x64 нет (если они всё же есть, буду признателен за ссылки в комментариях — обратите внимание, что речь идёт о Windows). Автор WPE Pro не оставил никаких контактных данных на официальном сайте и в самом сниффере, так что я принял решение разобраться в этом вопросе самостоятельно.

Как протекал процесс и что из этого вышло, читайте под катом.

С некоторых пор фирма Segger предлагает технологию Real Time Terminal (RTT) для своих JTAG адаптеров J-Link. Суть ее в том, что программа на микроконтроллере может выводить и принимать отладочную информацию из JTAG/SWJ-DP порта, как это обычно делается через UART. И тогда нам больше не нужен реальный отладочный UART. Далее чуть подробнее о возможностях этой технологии.

Вы когда-нибудь думали, что бывают игры, которые сами по себе являются языком программирования? Не обязательно Тьюринг-полным, но всё же языком. У меня есть отличный пример. Игровой процесс Нейрошимы-6 чудовищно похож на дебаг. Снаружи, конечно, смотрится как стратегия, но внутри – она, отладка, родная.

Посмотрите вот на эту картинку из жизни бойцов Пустошей.



Фишки с 20/20 – это командные центры, оставшиеся две — это фишки бойцов с ближней атакой по направлению треугольников по краям. Пока всё просто – синий робот с ножами бьёт желтого ковбоя, а ковбой бьёт по синему комцентру. Давайте усложним стек и запустим компиляцию.

Фреймворк Qt предоставляет неплохие средства разработки — входящая в него IDE Qt Creator включает дизайнер, отладчик, профайлер и другие удобные вещи. К сожалению, даже со всем этим иногда не очень понятно, почему приложение в данные момент выглядит так, как выглядит: чего-то не видно, что-то выглядит не так, как ожидалось, где-то неподходящий размер шрифта или неверная картинка.

Часть этих проблем может быть решена в Qt Designer, но только часть. Qt Designer имеет несколько существенных недостатков: во-первых, он неверно отображает положение Qt Quick компонентов в случае активного использования Javascript при расчете их координат и размеров, во-вторых в дизайнере мы видим состояние только «пустой» формы, без загруженных в неё данных. В общем, очень не хватает чего-то вроде инструментов разработчика в любом современном браузере: чтобы можно было посмотреть всё дерево компонентов, найти нужный, увидеть его положение относительно других, свойства, поправить на лету что-то, подобрать цвет\шрифт\размер, увидеть какие обработчики повешены на события и т.д.

И такой инструмент в мире Qt появился! Встречайте — GammaRay, средство интроспекции приложений на Qt. GammaRay понимает, что такое Qt, из чего состоит ваше Qt-приложение, как в нём взаимодействую компоненты, как они выглядят, как генерируются и обрабатываются события и т.д. Давайте посмотрим, что умеет GammaRay.

Продолжаем цикл статей о терминале/сниффере IO Ninja и переходим к рассмотрению одной из самых выигрышных сторон новой версии нашего продукта – программируемости. Она открывает новые применения такого, казалось бы, заурядного инструмента, как терминал или сниффер.

Обзор архитектуры плагинов

Как и в предыдущей, второй версии продукта, исполнимые файлы третьей версии IO Ninja содержат лишь фреймворк необходимых компонентов (включая UI виджеты, движок для логгирования и классы для работы с IO, такие как io.Socket, io.Serial, io.PCap и т.д.). Логика же работы с конкретными транспортами содержится в плагинах, написанных на языке Jancy. Эти плагины лежат в выделенной папке «scripts» в виде исходных кодов и доступны как для ознакомления, так и для редактирования пользователями.

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

В предыдущей статье мы разобрали, как реверс-инжиниринг может помочь в получении каких-либо преимуществ перед остальными пользователями. Сегодня мы поговорим ещё об одном применении обратной разработки — исправлении багов в отсутствии исходных кодов приложения. Причин заниматься подобными вещами может быть целое море — разработка программы давным-давно заброшена, а её сорцы автор так и не предоставил общественности / разработка ведётся совершенно в другом русле, и авторам нет никакого дела до возникшего у вас бага / etc, но их объединяет общая цель — исправить сломанный функционал, который постоянно вам досаждает.

Что ж, ближе к делу. Есть такая широко известная в узких кругах программа под названием «Govorilka». Как объясняет её автор, это ничто иное, как «программа для чтения текстов голосом». По сути, так оно и есть. При помощи неё было озвучено множество популярных и не очень видео, рапространившихся по всей сети. Программа имеет консольную версию под названием «Govorilka_cp», которую удобно вызывать из своих собственных приложений, что, собственно, я и сделал в одном из своих проектов.

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

Учитывая, что говорилка не обновлялась уже несколько лет, а сам автор оставил вот такое «послание» на своём сайте



, я понял, что надеяться мне не на кого, и решать проблему придётся самому.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

Предыстория

Два года назад компания Silicon Labs поглотила очередную компанию поменьше – на этот раз норвежского производителя малопотребляющих ARM-контроллеров EnergyMicro. С тех пор SiLabs активно развивает и продвигает микроконтроллеры серии EFM32 со смешной ящерицей на корпусе.

К делу

Если вам приходилось читать обзоры на современные микроконтроллеры, то вы согласитесь – кроме прочего там будет обязательно сказано о рекордно высокой производительности и о рекордно низком энергопотреблении. Кажется, это просто правило хорошего тона в клубе производителей МК, но случается что и шаблонные фразы маркетологов имеют смысл.

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



Под катом обзор утилиты и практические советы по её использованию.

Введение.

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

Вступление

В предыдущей статье я рассказал о своем первом знакомстве с DMA. В ней мы делали связку DMA + SysTick. Статья получилась очень специфичной и сложной, ввиду неопытного кривого подхода. Набравшись опыта, в данной статье я расскажу о куда более простом и понятном способе работы с DMA.

Перевод поста Стивена Вольфрама (Stephen Wolfram) «Scientific Bug Hunting in the Cloud: An Unexpected CEO Adventure».
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

Wolfram Cloud должен быть совершенным

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

Собственно, вот о чем речь. Как серьезная производственная система, которую многие люди будут использовать в том числе и для бизнеса, Wolfram Cloud должен работать как можно быстрее. Показатели говорили о том, что скорость достаточно хороша, но чисто субъективно чувствовалось, что что-то не так. Иногда всё было действительно быстро, но иногда казалось, что все работает слишком медленно.

В нашей команде есть отличные программисты, однако шли месяцы, и какие-бы то ни было изменений не ощущалось. А тем временем мы успели выпустить Wolfram Data Drop (см. статью на Хабрахабре «Wolfram Data Drop — новый сервис Wolfram Research»). Так что я подумал, почему бы мне самому не провести несколько тестов, возможно, и собрать немного информации в наш новый Wolfram Data Drop?

Существенное преимущество Wolfram Language заключается в том, насколько он хорош для занятых людей: даже если у Вас есть время только чтобы напечатать всего несколько строк кода (см. статью на Хабрахабре "Компания Wolfram Research открыла сервис Tweet-a-Program: интересных программ на языке Wolfram Language, длина которых не превышает 140 символов"), Вы сможете получить что-то действительно полезное. И, в данном случае, мне достаточно было просмотреть три строчки кода, чтобы найти проблему.

Сперва я развернул web API для простой программы на Wolfram Language в Wolfram Cloud:

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

В прошлой статье нам удалось получить звук, но это очень дорого нам далось. Во первых, мы разогнали контроллер до максимальной скорости. А во вторых, кроме генерирования звука контроллер ничего не может, так как большая часть процессорного времени занята постоянным обновлением значения ЦАП-а. Не хорошо это. Именно сейчас остро стоит вопрос об использовании ДМА.

DMA, или Direct Memory Access – технология прямого доступа к памяти, минуя центральный процессор.

— (с) отсюда.

Вступление

В предыдущей статье мы поговорили о настройке тактовой частоты микроконтроллера. Сейчас мне хотелось бы рассмотреть варианты работы со звуком: его генерирование и воспроизведение. По началу мне хотелось написать одну большую статью, в которой было бы рассмотрено все. От генерации прямоугольных импульсов до воспроизведения FLAC с microSD карты. Но статья получилось просто гигантской. Так что я решил разбить ее на несколько статьей поменьше. В каждой из которых я разбираю по одному периферийному модулю.

Общее представление о системе тактирования

В прошлой статье мы научились создавать стабильные задержки с помощью простого таймера SysTick, а так же немного окунулись в механизм работы прерываний. Тогда мы принимали как постулат то, что тактируя таймер от источника HCLK – мы получаем 8 Мгц. Теперь настало время разобраться, откуда эти цифры.