Представим следующую задачу: у нас есть микросервисная архитектура, в которой сервисы взаимодействуют через брокер сообщений, или через gRPC. Так или иначе, оба варианта предоставляют полнодуплексный канал связи, через который один сервис может отправлять множество сообщений другому сервису, так и в обратную сторону - сервис, исполняющий запрос, может отправлять несколько ответов (например в случае потоковой обработки данных). Такой вариант реализации ответа можно в некотором смысле называть стримингом.

В числе прочих задач, решаемых при реализации возможности стриминга, существует задача определения ситуации, в которой сервис, исполняющий запрос, упал с ошибкой, и больше не может продолжать стриминг ответов. В таком случае мы даже не можем понять что именно произошло - обработка и отдача очередной порции ответа будет, но задерживается, либо же передача прервалась, и нужно сообщить об ошибке “наверх”. В протоколе HTTP, например, для детерминирования корректной вычитки ответа может быть использован заголовок Content-Length. Достаточно посчитать количество вычитанных из сокета байт тела запроса\ответа, и сравнить со значением заголовка. Сходится - мы все получили, не сошлось и сокет закрыт - ошибка. Однако вариант решения с заранее заданным количеством данных в первой порции ответов не является универсальным, поскольку не во всех случаях можно точно понимать, сколько именно данных будет передано. Да и архитектура с использованием брокеров сообщений предполагает постоянное поддержание соединения, поэтому мы можем только знать, что из такой-то очереди поступают ответы на ранее сделанный запрос, и в каком-то из ответов будет метка окончания, как маркер того, что запрос обработан и ответ выслан и получен полностью, а если такого маркера еще не получено - остается продолжать ждать. Но ждать можно бесконечно.

В самом начале своей карьеры я имел честь в одно лицо разрабатывать проект, предназначенный для массового пользователя. Надо сказать, что почти все основополагающие принципы того, как провалить проект, были соблюдены, однако, он до сих пор жив. Проект был предназначен для принудительного использования определенной категорией работников бюджетной сферы. Технического задания, аналитики, дизайн-документов, макетов в Фигме, лавандового смузи, и прочих этих ваших модных слов, без которых N лет назад строили БАМ и Траннсиб не было от слова совсем. Зато, были процессы “в бумаге”, которые требовалось оцифровать. Поэтому то, что можно было принять за ТЗ, выглядело как “Эти (работники) заполняют вот это (бумаги) потом несут тем (проверяющим) а дальше все это хранится, сделай чтобы они с компьютера могли загрузить и отправить, у нас тут целый этаж бумагами занят, пожар начнется - всему хана”. Используя весь свой багаж знаний и опыта в построении высоконагруженных систем (на этом месте я отошел от написания статьи сначала проржаться а потом поплакать), я приступил к реализации.

Предупреждение

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

Введение

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

Предупреждение

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

Введение

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

Если вам когда-нибудь приходилось работать с NumPy, то вы скорее всего знаете, что в индексатор массива можно передать не только индексы начала, конца, и шага. Потрясающая возможность - получить срез массива по некоторому условию, в виде data[data > 0] предает массивам NumPy некоторое сходство с СУБД.

Тут же можно вспомнить про SqlAlchemy и возможность передать в функцию filter некоторое условие для отбора записей session.query(MyModel).filter(MyModel.field == 10).

Отличные, в общем-то возможности, не так ли? Не возникало ли у вас вопроса как они работают внутри? data > 0 и MyModel.field == 10 с точки зрения грамматики языка являются выражениями, и при передаче куда-либо Python попытается вычислить их значения. Попробуем разобраться как это работает.

О чем статья: при разработке проектов, и, особенно, распределенных приложений, возникает необходимость использования некоторых частей приложения в качестве отдельных модулей. Например скомпилированные классы для gRPC, модули для работы с БД, и многое другое, могут применяться в неизменном виде в кодовой базе десятка микросервисов. Оставив за скобками копипасту, как "хорошую" плохую практику. Можно рассмотреть git submodules, однако, такое решение не очень удобно тем, что, во-первых, нужно предоставлять разработчикам доступ к конкретным репозиториям с кодовой базой, во-вторых, нужно понимать, какой коммит надо забрать себе, и в-третьих установка зависимостей для кода, включенного в проект как субмодуль, остается на совести разработчика. Менеджеры пакетов (pip, или, лучше, poetry), умеют разрешать зависимости из коробки, без лишних действий, и, в целом, использование менеджера пакетов значительно проще, чем работа с субмодулем. В статье рассмотрим, как организовать реестр пакетов в GitLab, а также различные подводные камни, поджидающие на пути к удобной работе с ним.

Для кого: статья будет полезна разработчикам, столкнувшимся с необходимостью организации приватного реестра пакетов, в качестве руководства по организации такого реестра в GitLab.

Трассировка и анализ ошибок в микросервисной архитектуре без средств централизации логирования обычно причиняет неудобства, поскольку для понимания “что и на каком микросервисе умерло” приходится обходить микросервисы по очереди, сверять и сопоставлять данные в логах. В данной статье рассматривается централизация логирования с помощью Graylog, с примерами кода на Python.

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

Несмотря на то, что с момента публикации второй части прошло почти полгода — прокрастинация все-таки выиграла битву, но не войну, и поэтому повествование о нелегких буднях в НИИ Велосипедостроения продолжается. В предыдущих частях рассказывалось об общей концепции и предпосылках, и MVP для сервера, отвечающего за запуск преднастроенного контейнера с openssh, и отслеживание состояния клиента, подключенного через websocket. В третьей части статьи поговорим о рисках в части безопасности, и реализации клиентского приложения.

Перефразируя известного персонажа, чью роль исполнил Саша Барон Коэн, можно с уверенностью утверждать, что безопасность данного решения это боль в моя…в общем, если смотрели фильм, то понимаете о чем я.

Привет, Хабр! 

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

Прежде чем приступить к изложению сути темы, расскажу историю из практики. Когда-то я занимался автоматизацией такого страшного явления как “аттестация педагогических работников”. Суть заключалась в том, чтобы разработать систему, куда доблестные труженики образования загрузят документы, подтверждающие успехи в работе - грамоты, дипломы учеников, и далее по списку. Стек: PHP+Python (если хотите знать, что тут делает Python - почитайте первую статью), JS (jQuery) на фронте. 

Конечно же, никакого ТЗ не было, порядок внесения изменений напоминал постройку железной дороги прямо перед движущимся паровозом. Закономерным следствием такого подхода стали некоторые “особенности” в работе системы. Так, например, список отправленных на рассмотрение портфолио для администратора формировался несколько минут. Однако это всех устраивало, потому что “внесение изменений может что-то сломать, а так оно работает пусть медленно, зато предсказуемо”. Оно и по сей день работает медленно, но предсказуемо.

В своей первой статье на Хабре я описывал опыт реверсинга и модификации проекта, доставшегося по наследству. Конечно, в отношении проекта на Python "реверсинг" - это гипербола, однако с чем-то ранее неизвестным столкнуться все же получилось. Если вкратце - вместо классических исходников использовались модули, загружаемые из .pyc, а не классических .py файлов. Философия "защитников" базируется на принципе "Там сложно, никто не разберется".

Ход событий же показал, что во-первых не так уж и сложно (передача параметров в хранимую процедуру PgSQL, и получение результата, возврат его пользователю - далеко не шедевр обфускации, скорее тут будет более применим принцип "Там несложно, любой разберется, но не захочет"), а во-вторых - кто-нибудь да поймет и найдет способ изменить поведение в нужном ключе. 

Привет, хабр! 

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

- "Дима, сделай Алевтине Генриховне виртуальную машину, чтобы она могла изучать систему, и свяжись с ней для настройки подключения" - именно с такой задачи начинается процесс обучения нового сотрудника в нашей компании.

- "Ну сейчас начнется" - думаю я. 

- “VPN настраивать не умею”, “У меня все зависло”, “По инструкции настроить не получилось” - подобные реплики от “бизнес-аналитика Алевтины Генриховны” слышно с завидной регулярностью.

Приходится связываться, подключаться одним из доступных способов, и настраивать всё самому. Хорошо если все работает с первого раза. Плохо, если в системе по какой-то причине не работают службы, драйверы минипортов, и т.д. Однако, подключаться и помогать всё равно приходится чаще, чем хотелось бы. С очередной Алевтиной Генриховной этот процесс мне изрядно надоел, и я стал думать над поиском решений, способных облегчить жизнь.