Прочитав статью про семь соприкасающихся цилиндров, я задумался: действительно ли эта задача такая сложная? Или ей просто раньше никто всерьёз не занимался?
Положение бесконечного цилиндра известного радиуса в пространстве задаётся четырьмя независимыми величинами (имеет 4 степени свободы). Для семи цилиндров в общем положении потребуется 28 величин. Каждое условие «два цилиндра касаются» даёт одно ограничение, всего остаётся 7 степеней свободы. Шесть из них — перемещения пространства, последнее остаётся на саму конфигурацию. То есть, у нас должно получиться одно или несколько однопараметрических семейств конфигураций, если только не помешает топология (из-за которой решений может не оказаться вообще).
Вместо цилиндров нам удобнее работать с прямыми. Если диаметры двух цилиндров одинаковы и равны, допустим, единице, то они касаются (внешним образом) тогда и только тогда, когда расстояние между их осями равно единице. Учтём этот факт, и пойдём искать семь красных перпендикулярных прямых...

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

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

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

Для более или менее адекватного восприятия статьи потребуется минимальные знания ассемблера (его будет много) а так-же навыков работы с отладчиком.

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

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

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

Вот первоначальная ссылка, где он появился: http://exelab.ru/f/index.php?action=vthread&forum=1&topic=4732
А потом он попал вот сюда: http://www.crackmes.de/users/ms_rem/keygenme_by_ms_rem/
Где данному keygenme был выставлена сложность 8 из 10 (*VERY VERY* hard).
Хотя, если честно, это слегка завышенная оценка — я бы поставил в районе 5-6 баллов.

Пожалуй, начнем.

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

Существует немало методов, однако наибольший интерес представляют те, которые могут быть формализованы, а соответственно запрограммированы без особых сложностей. А также работающие с произвольными булевыми выражениями. Идеального метода не придумано, все имеют те или иные слабые и сильные качества. Я остановлюсь на так называемом методе Гиперкубов — Методе Квайна.

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

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

Что же всё-таки можно нарисовать с помощью всего двух треугольников? Квадрат? Фрактал? Полёт сквозь мегатонной мощности взрыв в центре города? Есть ли предел безумию, где заканчивается реальность и начинается явь? Как правильно ухаживать за лучами, чем их кормить и обо что отражать вы узнаете во внезапном продолжении цикла статей про демомейкинг!

В этом посте я расскажу про программу, которая подделывает любую подпись при помощи шарнирного механизма. Программа основана на теореме Кемпе, доказанной в середине 19-го века.

Qt хорошо известен своим механизмом сигналов и слотов. Но как это работает? В этом посте мы исследуем внутренности QObject и QMetaObject и раскроем их работу за кадром. Я буду давать примеры Qt5 кода, иногда отредактированные для краткости и добавления форматирования.

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



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

В своей статье я хотел бы рассказать о теории относительности. Эта теория не требуется в представлении. С самого своего создания она была окутана ореолом тайны, поскольку полностью подрывает наши привычные представления о пространстве и времени. Все мы в школе учили формулы теории относительности, но мало кто действительно понимал их. И это не удивительно, ведь человеку, чтобы по-настоящему понять какую-то теорию во всей её красоте, полноте и непротиворечивости, не достаточно знать формулы. Нужно иметь какой-то визуальный ориентир, нужна динамика, чтобы было что-то, что можно повертеть в руках. Я решил восполнить этот пробел и написал небольшую программку, в которой можно «повертеть в руках» пространство-время. Мы, как настоящие исследователи, с помощью небольших экспериментов попытаемся выяснить основные свойства этой загадочной материи.
Под катом много картинок (и ни одной формулы).

1. Фильтры захвата

Анализаторы трафика являются полезным и эффективным инструментом в жизни администратора сети, они позволяют «увидеть» то что на самом деле передается в сети, чем упрощают диагностику разнообразных проблем или же изучение принципов работы тех или иных протоколов и технологий.
Однако в сети зачастую передается достаточно много разнообразных блоков данных, и если заставить вывести на экран все, что проходит через сетевой интерфейс, выделить то, что действительно необходимо, бывает проблематично.
Для решения этой проблемы в анализаторах трафика реализованы фильтры, которые разделены на два типа: фильтры захвата и фильтры отображения. Сегодня пойдет речь о первом типе фильтров – о фильтрах захвата.
Фильтры захвата, это разновидность фильтров, позволяющая ограничить захват кадров только теми, которые необходимы для анализа, уменьшив, таким образом, нагрузку на вычислительные ресурсы компьютера, а также упростив процесс анализа трафика.

Когда писалась эта статья, хабрапоиск по словосочетанию «Генетический алгоритм» выдавал благородную пустоту. Однако недостаточный уровень *вырезано цензурой* отодвинул дату публикации, и вот только сейчас после позорного нудливого попрошайничества с моей стороны эта статья получила возможность показать себя миру. За этот промежуток времени успели выйти в свет как минимум три (столько мне на глаза попалось) статьи на подобную тему, и, вполне вероятно, что-то из написанного ниже вы прочитаете не впервые. Таким людям я предлагаю не хмурить носики от очередной попытки неопытного юнца научно-популярно объяснить ГА, а проходить к следующему экспонату ко второй части, где описывается создание на основе ГА бота для программистской игры Robocode. Это, по последним сведениям разведки, еще не встречалось на хабре.

Часть первая. Жизнь и творчество генетического алгоритма.

Начнем издалека. Есть некоторый набор задач, которые требуют решения. Наша цель — найти действия, которые смогут преобразовать Дано (начальные условия задач) в Ответ (целевое состояние).

Если ситуация простая, и решение такой задачи можно явно посчитать из условий при помощи этих ваших матанов, то и славно, тут и без наших премудростей все хорошо, нас наебали, все расходимся. Например, при решении квадратного уравнения ответ (значения x1, x2) получаются из начального условия (коэффициентов a, b, c) путем применения формулы, которую мы все учили в школе. А что делать в более печальном случае, когда нужной формулы в учебнике нету? Можно попробовать с помощью мозгового штурма решить одну из задач. Аналитически. Численными методами. Силой отчаянного перебора функций. Через некоторое время послышатся мечтательное студенческое «хоть бы оно само решилось». Ага, тут-то мы и вылезаем из-за занавесок. Итак, цель — написать программу, которая бы находила функцию (программу), получающую на вход исходные данные и возвращающую годные циферки. Сила метапрограммирования, в бой!

От переводчика: это перевод статьи Кристиана Глобмайера The Ten Rules of a Zen Programmer. Статья мне понравилась, решил сделать перевод, после окончания перевода загуглил название, нашел вариант перевода: 10 принципов дзен программиста. Отличается от моего, поэтому решил свой вариант перевода все-таки запостить.

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

Одним дождливым утром я сидел за своим столом и думал об эффективной работе. До того, как я начал работать фрилансером, у меня бывало, что я работал много, но никогда не был доволен результатом. Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать. Хотя я не люблю посты «как быть лучшим программистом», я хочу рассказать о некоторых моих мыслях с того времени. Этот пост будет служить мне напоминанием, но если у вас есть идеи, не стесняйтесь оставлять комментарии.

SAT уже тем хорош, что он ум в порядок приводит
Ломоносов (оригинал)

Введение

На хабре уже немало статей, посвященных проблеме P vs. NP и задаче о выполнимости логических формул (SATisfiability problem). Однако, большинство из них не отвечает на несколько самых важных вопросов. Почему эта проблема действительна важна для нас? Что будет, если её решат? Где это все вообще применяется? И почему необходимо иметь хотя бы общее представление, о чем там идет речь?



Если мы детально проанализируем наиболее заметные работы на хабре по данной теме [1, 2, 3, 4, 5, 6, 7], то заметим, что с одной стороны, люди обладающие знаниями в области вычислительной сложности не cмогут почерпнуть ничего принципиально нового в данных статьях. С другой стороны, данные статьи по-прежнему не являются общедоступными. Иллюстрация из заголовка наглядно демонстрирует проблему: тем, кому было не понятно, из неё ничего не ясно, а те, кто об этом уже слышал, в ней не нуждаются.

Данная статья преследует две цели: первое — дать общее представление о проблеме и ответить на вопрос, почему же нам стоить знать об этой задаче (первая часть), второе — предоставить материал «на вырост», который будет интересен людям интересующимся тематикой, а так же может быть полезен для изучения темы в дальнейшем (вторая часть).

Многие мои друзья и знакомые крутят пальцем у виска или задаются вопросом: не жмёт ли мне череп, когда узнают, что я пишу драйвера под Linux. Слово “драйвер” окутано каким-то почти мистическим смыслом, и постичь Дао его написания способны лишь избранные гуру.
К счастью это не так. Не знаю, как обстоят дела с написанием драйверов под другие операционные системы, в т.ч. и наиболее популярные, но под linux, вне зависимости от аппаратной архитектуры драйвера пишутся очень просто. Для написания драйвера необходимы базовые знания языка си, представление о работе ОС линукс (базовые), понимание того, что мы хотим получить, желание чтения документации и исходных кодов, ну и усидчивость. Всё.
Вы хотите посмотреть как написать драйвер для своего устройства? Тогда ныряйте под кат!

Девять лет назад я посещал курс физики в колледже, и мой профессор рассказал одну вещь, которая поразила меня. Я думаю, не будет преувеличением сказать, что это одно из наиболее широко используемых математических открытий — от оптики до квантовой физики, радиоастрономии, сжатия MP3 и JPEG, рентгеновской кристаллографии, распознавания голоса и МРТ. Этот математический инструмент называется преобразование Фурье, в честь французского физика и математика 18-го века Жозефа Фурье. Им пользовались даже Джеймс Уотсон и Фрэнсис Крик, чтобы декодировать структуру двойной спирали ДНК из рентгенограмм, произведенных Розалиндой Франклин. (Крик был экспертом по преобразованиям Фурье, он в шутку назвал свою книгу «Преобразования Фурье для орнитологов», чтобы объяснить суть Уотсону, заядлому любителю птиц).

Познакомившись с магией систем компьютерной алгебры, я провела несколько вечеров в странных и на первый взгляд бессмысленных занятиях — перерешивая вузовские задачки по алгебре, математическому анализу, дифференциальным уравнениям… Просто потому, что было интересно — найдется ли такое уравнение, которое не смогут решить ни Maple, ни Maxima? В моем арсенале были эти две системы, и со всеми проблемами они справлялись «на ура». Это вовсе не означает, что всё решалось мгновенно и без применения математических знаний. Некоторые задачи требовали особых подходов, многочисленных преобразований и замен переменных. Так что, с противниками компьютерной алгебры можно поспорить — при правильном применении она нисколько не расслабляет мозг, а наоборот — развивает логическое (и прочее) мышление.

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

Недавно на Хабре в одной статье упомянули про вопрос «Что было бы с миром, если бы число Пи равнялось 4?» Я решил слегка поразмышлять на эту тему, используя некоторые (пусть и не самые обширные) знания в соответствующих областях математики. Кому интересно – прошу под кат.

Некоторые из вас, вероятно, видали на просторах сети эту задачку: какое число продолжает следующий ряд?

Предлагался такой очевидный правильный ответ:

Для тех, кому неочевидно, как он получен, предлагалось объяснение. Пусть (ну и 1 при x = 0, хотя неважно). Тогда каждый член ряда — это значение следующего интеграла в цепочке:

Пока всё идёт хорошо, но тут внезапно:

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

Давно хотел написать этот пост с подборкой полезных ссылок, так как очень часто спрашивают подобное (думаю, у многих, кто в этой (да и в других) сфере). Ссылки разбиты на категории.

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

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

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.