Говнокод

Разворачивал в очередной раз Linux-образ на USB-drive (почему-то им оказался Manjaro, но это совсем другая история), и в голову пробрались странные мысли: BIOS увидел флешку, а дальше-то что? Ну да, там MBR, скорее всего GRUB и… А раз в MBR затесался чей-то кастомный код, значит и простой человек из Адыгеи может запрограммировать что-нибудь на «большом» компьютере, но вне операционной системы.

А так как делать такие штуки на языках высокого уровня слишком жирно, а ассемблеров мы не знаем, будем шпарить прямо на опкодах для 8086.

Примечание

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

Введение

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

• hackerone.com
• bugcrowd.com
• intigriti.com
• yeswehack.com
• openbugbounty.org
• synack.com (privat)

Как это работает ?

• Ищем уязвимости
• Пишем сделанные шаги необходимые для эксплуатации уязвимости
• Скидывает этот отчет тех. поддержке.
• Получаем монетку.

Что нам нужно для этого?

VPS, желательно Debian (могут использоваться и другие) + хорошее интернет-соединение ( я беру у alexhost.com, VPS 1.5 GB RAM, 1 Core, 10GB SSD всего за 11 евро в год. )

• sublist3r
• httprobe
• webscreenshot
• header response
• relative-url-extractor
• jsfiles extractor

PieceofScript — простой язык для написания сценариев автоматического тестирования HTTP JSON API.

PieceofScript позволяет:

• описывать методы API в формате YAML, с названием метода на почти естественном языке, что удобно для чтения тестов
• достаточно гибко описывать модели в формате YAML и генерировать по ним рандомные данные
• писать сложные сценарии вызовов API на легкочитаемом языке с несложным синтаксисом
• получать результаты тестирования в форматах JUnit и HTML

Я написал этот «велосипед» потому что меня вгонял в уныние интерфейс SoapUI. Хотелось просто и понятно описывать тесты в текстовом редакторе без специального GUI. Кроме того, git плохо переваривает огромный xml-файл, который выдает SoapUI, поэтому тесты на конкретную задачу сложно положить в той же ветке, где сделана сама задача. Интерфейс Postman куда приятнее, но при разработке много времени уходит на составление/изменение там запросов и повторение их в нужной последовательности. Это хотелось автоматизировать. Я изучил еще и другие инструменты тестирования, у каждого был "фатальный недостаток", поэтому в припадке NIH-синдрома я открыл IDE.

Вот что из этого вышло.

Пост актуальный для майских праздников. 6 недель назад я подал документы, чтобы получить визу в Ирландию. Вылет запланирован на 30 апреля. Существует сайт посольства, на котором публикуются списки решений по визам. Они это делают по понедельникам и четвергам. И вот я сижу в воскресенье, 28 апреля, по моей визе решения еще нет. И дальнейшие мои действия в понедельник зависят от того, будет ли мое заявление в новом отчете или нет. Если нет, то надо будет ехать в посольство и разбираться. Если есть, то дергать визовый центр. Сидеть и обновлять страничку целый день в понедельник казалось унылым времяпрепровождением, поэтому я написал скрипт на Python.

Disclaimer. Я не программист, но умею программировать. Это значит, что я не могу написать изящный и эффективный код, но я могу заставить эту шарманку делать то, что мне от нее нужно.

Проблема избыточной скорости работы

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

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

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте.

Всем привет!

Я работаю тимлидом команды Integration Development в сервисе онлайн-бронирования отелей Ostrovok.ru и сегодня хотел бы поделиться своим опытом работы с различными API.

Как разработчик системы, работающей с внешними поставщиками, я часто встречаюсь с различными API – чаще всего это SOAP/REST или что-то на них похожее. Однако от работы со многими из них остается впечатление, что их писали, не руководствуясь ни техническими правилами, ни здравым смыслом – как будто бы по книге “Вредные советы” Григория Остера. В данной статье я постараюсь описать такие случаи в стиле “вредных советов” и рассмотрю примеры, связанные с XML. Комментарии и обсуждение приветствуются.

Многим знаком Scratch – детская среда программирования, обучение в которой обычно сводится к созданию творческих проектов по принципу «от простого к сложному». При этом «классический подход» к изучению программирования (переменные → ветвления → циклы → функции → структуры → объекты → …) в Scratch затруднителен.

Однако изменение последовательности изучения понятий (назовем их концепциями) структурного, объектно- и событийно-ориентированного программирования, их сокрытие за яркими спрайтами и интерактивной анимацией, не означает, что на концепциях не следует делать акцент. Особенно, если целью ставится не столько развитие творческих способностей, сколько обучение программированию.

Как-то вечером я убивал время, читая статьи в интернете, и наткнулся на вот этот хабропост пользователя Cyapa, где расписано, как кастомизировать select на чистом css. В процессе просмотра данного решения нашел несколько весьма неудобных моментов, которые постарался исправить в своем решении этой задачи. Итак, приступим.

Ковыряясь в разнообразном СПО, я периодически нахожу всякие интересные штуки: иногда это просто смешной комментарий, иногда — нечто остроумное в более широком смысле. Подобные подборки периодически появляются и в «глобальном Интернете», и на Хабре — есть, скажем, широко известный вопрос на StackOverflow про комментарии в коде, а здесь недавно публиковалась подборка забавных названий юрлиц и топонимов. Попробую и я структурировать и выложить то, что постепенно у меня копилось. Под катом вас ждут цитаты из QEMU, ядра Linux, и не только.

Совсем небольшое сообщение.

По ряду личных причин я люблю таскать свой инструментарий на флешке или внешнем жёстком диске. Одним из инструментов является IDA 6.8.

После работы с системами я не люблю, когда остаются какие-то хвосты в реестре или в виде файлов. И к сожалению, IDA и её модули (в частности, BinnDiff) этим грешны.

Ну и возникло желание получить полностью портабельный комплекс.

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

Метод walkFileTree() позволяет обойти дерево файлов и поддиректорий передаваемого ему в качестве параметра элемента Path…

Решили мы однажды заняться автоматизацией наших рутинных рабочих моментов. Создать у себя ансамбль(ansible) или что-нибудь в этом роде. Я полез на сайт ансамбля, посмотрел как он работает … подключается к удаленному серверу через ssh и выполняет какие-то там скрипты... Стоп, подумал я, разве для этого нужен ансамбль? Я и без ансамбля, сам ..., один… могу это сделать! А чтобы не только лишь я это мог, решил написать вэб приложение. Приложение назвали Update Server, сокращенно UpS.

Ворнинг! Под катом много картинок и пара гифок.

Возникновение идеи

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

Автоматизация заполнения и вывода файлов по шаблонам рутинных документов это одна из та областей в отрасли строительства по которой традиционно софт, кроме бухгалтерского, находится на уровне вылизанных поделок, на мой скромный взгляд. Поэтому, развивая тему, приглашаю обсудить те проблемы и возможности, с которыми пришлось столкнуться в процессе реализации на базе MS Excel.

Типичный юзкейс для Kibana — смотрим логи, видим ошибки, создаем тикеты по ним. Логов у нас довольно много, места для их хранения мало. Поэтому просто вставить ссылку на документ из Elasticsearch/Kibana недостаточно, особенно для низкоприоритетных задач: пока доберемся до нее, индекс с логом может быть уже удален. Соответственно, приходится документ сохранять в файл и прикреплять к тикету.

Если один раз это делать, то это еще куда ни шло, но создавать уже десять тикетов подряд будет тупо лень, поэтому я решил это «быстренько» (ха-ха) автоматизировать.


Под катом: статья для пятницы, экспериментальная фича javascript, пара грязных хаков, небольшая регулярка с галочками, reverse proxy, проигрыш безопасности удобству, костыли и очевидная картинка из xkcd.

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

upd: Осторожно, текст содержит сатиру и кодобред

Язык программирования PHP берёт своё начало в 1995 году и является продуктом эпохи зарождения современных веб стандартов, таких как http (версия 1.0 — 1996), html (версия 2.0 — 1995), javascript (1995 год), url (1990 — 1994 года). Первоначально аббревиатура php имела расшифровку Personal Home Page Tools, далее трансформировавшись в Hypertext Preprocessor или «препроцессор гипертекста». Об использовании PHP в качестве препроцессора и будет посвящено несколько следующих абзацев.

Впервые про TECO я прочитал в пародийной статье Real Programmers Don't Use Pascal, написанной незадолго до моего рождения. Там было написано, что настоящие программисты не используют новомодные редакторы EMACS и VI:

Нет, Настоящий Программист хочет редактор вида «Просил? Так получай!» — сложный, загадочный, мощный, не прощающий ошибок, опасный. TECO, если быть точным.

Оригинал

No, the Real Programmer wants a `you asked for it, you got it' text editor — complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

Это меня заинтриговало. Что за зверь такой, можно ли его пощупать? Википедия рассказала, что TECO — это Text Editor & COrrector, создан он в 1962-м году в DEC и использовался на компьютерах семейства PDP, а позже на системах OpenVMS. Оказалось, что существует порт на Си, который поддерживается энтузиастами в актуальном состоянии и собирается под современными операционными системами. Вот я и решил почувствовать себя настоящим программистом хотя бы немножко.

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

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