Привет, Хабр! Недавно мы проводили конкурс компьютерных историй на Пикабу, а также при поддержке Ростелекома дарили участникам мероприятия утят. В этом посте я хочу рассказать, как это было и поделиться историями участников, а также поговорить о том, насколько важен утенок в работе айтишника.
Любите кря-кря? Давайте под кат.
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
Это отладочное приключение Брюса Доусона, разработчика Chrome и блогера, позволило снизить загрузку процессора при работе с веб-камерой примерно на 3% - настоящая помощь для тех, кто полагается на видеозвонки.
Сервис Sentry позволяет удаленно мониторить баги в фронтенд-приложениях, написанных на JavaScript.
Попытка устранить проблемы в фронтенд-приложениях на JavaScript может оказаться непростой задачкой, поскольку они возникают в браузере пользователя, к чему, зачастую, у вас нет доступа. Однако, Sentry дает возможность удаленно мониторить баги.
Долго думал, можно ли переопубликовывать статью на Хабре, проштудировал правила, вроде как сейчас это не возбраняется. Если ошибся — исправлюсь :)
Итак...
Какое-то время назад я писал код прошивки для грабберов Epiphan линейки AV.io:
Там был задействован Cypress FX3, а SDK был построен поверх ThreadX. В качестве JTAG отладчика можно использовать Olimex ARM-USB-OCD-H в связке с OpenOCD. К сожалению, OpenOCD ничего не знает про треды в RTOS и, хотя, базовая поддержка присутствует в коде, конкретно для нашего процессора использовалась схема стекинга регистров, которая отличалась от того, что было уже реализовано. Пришлось разбираться и дорабатывать. Профиты от использования JTAG для разработки трудно переоценить, как минимум в случае распределённой работы.
Итак, время идёт. Теперь очередь за FPGA от Xilinx и его софтовым процессором MicroBlaze, где можно запустить портированый FreeRTOS версии 10.x. Но проблема ровно такая же: поддержки тредов в отладчике нет!
В сети не много информации о появившемся несколько лет назад GDB сервере EBlink. Этим постом постараюсь исправить ситуацию.
EBlink поддерживает большинство моделей микроконтроллеров STM32 (серии F0, F1, F2, F3, F4, F7, H7, L0, L1, L4, G0 и G4), а также EFR32.
Он интересен тем что поддерживает скрипты на Си-подобном языке Squirrel которые участвуют в процессе прошивки и отладки микроконтроллеров. Это позволяет отредактировав скрипты добавить новые микроконтроллеры или изменить работу с существующими не вмешиваясь в исходный код EBlink. Могу предположить таким образом возможно добавить микроконтроллеры с ядром ARM Cormex-M других производителей, например компании Миландр но это не было проверено.
Привет, Хабр! Представляю Вашему вниманию перевод статьи «6 Tips To A Successful Code Review».
Сode review во все времена являлся основополагающей практикой, отвечающей за создание чистого и поддерживаемого кода.
Частенько разработчики пренебрегают и недооценивают code review по причинам, которые кажутся в тот момент объективно правильными.
Давайте сегодня сформулируем 6 советов, чтобы провести качественный и плодотворный code review.
Делая пере-реализацию QInst на LLVM, я столкнулся с такой проблемой: QEMU в режиме эмуляции одного процесса естественным образом перехватывает все «гостевые» системные вызовы. В итоге плагин инструментации имеет единую точку входа для их предобработки, где можно по номерам SYS_* и значениям аргументов принимать решения. Это довольно удобно. Проблема в том, что все системные вызовы делает, в основном, libc и, переписывая код статически, мы просто до этой части в большинстве случаев не доберёмся. Конечно, можно было бы использовать ptrace, который как раз предназначен и для этого в том числе. Но тогда не уверен, что получилось бы обойтись без отдельного процесса, а семантика QInst предполагала тривиальный «синхронный» перехват — пришлось бы как-то инжектить вызов обработчика, а это сильно сложнее привычного LD_PRELOAD. Можно оборачивать каждый системный вызов — но это, как минимум, неудобно (к тому же, можем что-нибудь пропустить, ведь в этом случае мы перехватываем на самом не системные вызовы, а их конкретные обёртки).
Под катом — решение, не привязанное к LLVM, но заточенное под Linux на x86_64 (но адаптируемое для Linux на других архитектурах).
Примечание: в этой статье не представлено универсального готового решения — оно лишь подходит для достаточно широкого списка случаев. Зато эту статью можно считать обзорно-пятничной: интересная (надеюсь) новая (для большинства?) информация, щепотка брутфорс-программирования и рабочие примеры. И пусть нашу пятницу не омрачает даже тот факт, что сегодня четверг!
Под катом представлен перевод презентации "The Windows Notification Facility: The Most Undocumented Kernel Attack Surface Yet", представленной Alex Ionescu и Gabrielle Viala на конференции BlackHat 2018.
Выпускаю первую ВМ. По сети не пингуется. Локально с гипервизора — всё ок. Лезу на консоль, запускаю что-то типа "tcpdump -nvvvi any" (по-умолчанию выставляется promisc-режим) — ping побежал. Выключаю tcpdump — опять глухо. При запуске с ключом "-p" (запретить неразборчивый режим) tcpdump вообще ничего не видит.
Язык программирования Go (так же известный как Golang) с каждым днем все больше и больше программистов хотят на нем писать программы. Для хакеров этот язык программирования становится еще более привлекательным за счет кросс-компиляции для различных платформ - Windows, Linux, MacOS. Например, хакеры могут написать загрузчик на Go, внутри может быть ВПО, созданное с использованием более распространенного языка.
На Go также пишутся так называемые дропперы, использующиеся для декодирования, загрузки и установки ВПО. Все идет к тому, что Go, вероятно, будет еще чаще использоваться злоумышленниками. Уже появлялись и шифровальщики использующие Go для шифрования основного вредоносного модуля. Одним из самых примитивных примеров использования Go - написание кроссплатформенного ReverseShell . Отсюда и вытекает необходимость реверс-инжиниринга бинарных файлов написанных на язке Go.
Некоторые особенности языка программирования Go усложняют задачу реверс-инженерам при исследовании бинарных файлов Go. Инструменты обратного проектирования (например, дизассемблеры) могут отлично справляться с анализом двоичных файлов, написанных на более популярных языках (например, C, C++, .NET), но Go создает новые проблемы, которые делают анализ более громоздким.
Бинарные файлы Go обычно статически связаны, что означает, что все необходимые библиотеки включены в скомпилированный бинарный файл. Это приводит к большим размерам файла, что затрудняет распространение вредоносного ПО для злоумышленников. С другой стороны, некоторые продукты безопасности также имеют проблемы с обработкой больших файлов. Это означает, что большие двоичные файлы могут помочь вредоносным программам избежать обнаружения. Другое преимущество статически связанных двоичных файлов для злоумышленников заключается в том, что вредоносное ПО может работать на целевых системах без проблем с зависимостями.
Привет! Я Антон Антонов, Full Stack Developer. Хорошее, подробное исключение — мощный инструмент, который помогает найти и исправить проблему. Поэтому в исключения стоит вносить больше деталей. Расскажу, как использовать свойство Exception.Data, чтобы логировать дополнительные сведения об исключениях.
В процессе переделки игрушки-осциллографа DSO138, как уже описывалось в предыдущей статье, возникла идея в DSO303 попробовать фокус с удвоением частоты дискретизации. В самом деле для STM32F303 теоретически максимально достижимая скорость дискретизации с точки зрения входа АЦП, а это определяется минимальным временем открытия УВХ, которое в нашем случае 1,5 такта х (1 / 72 МГц), или примерно 20,8 наносекунд, что дает 48 MSPS (миллионов отсчетов в секунду). Однако при параллельной работе 4-х АЦП на 6 МГц получается достичь только 24 MSPS из-за ограниченного быстродействия АЦП.
Представим себе, что мы рассматриваем правильно-периодический сигнал, который при этом еще и постоянен, т.е. не испытывает флуктуаций по частоте и амплитуде во времени. Возможно ли как-то оцифровывать его не в один, а в несколько проходов, тем самым увеличив эффективную частоту выборки?
