Уже не является секретом тот факт, что полные исходные тексты известного банковского вредоносного ПО Carberp утекли в паблик. Около 5GB исходных текстов оказались в поле зрения фактически любого желающего. Архив включает в себя:

• Исходный текст буткита, km драйверов и всего что работает в km.
• Билдер дропперов.
• Плагины.
• Веб-инжекты.
• LPE эксплойты.
• Огромное количество другой полной и необходимой информации, чтобы начать свой собственный проект по разработке вредоносного кода.

Как и в случае с Zeus, история началась с того, что архив с текстами был выставлен на продажу на нескольких подпольных форумах. Ниже представлен пост с объявлением с одного из форумов. Первоначально информация о том, что исходные тексты Carberp были выставлены на продажу была опубликована Trusteer 18-го июня, т. е. около недели назад. При этом указывалось, что цена архива составляет $50,000. Но позже на одном из форумов появилась информация, что тексты продаются по очень низкой цене, всего лишь $5,000. Архив включает в себя тексты вредоносного кода и купленные сторонние наработки с 2008 г.

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

Недавно к нам обратился заказчик с просьбой помочь в организации небольшого Call-центр на 10 операторов. Ну конечно одно из главных требований – «подешевле».
Было предложено несколько решений, остановились на следующем, базирующемся полностью на VoIP технологии:

• 4 городских аналоговых линии принимаются голосовым шлюзом D-Link DVG-6004S
• в роли IP АТС и сервера с CRM-системой выступает сетевой накопитель D-Link DNS-325
• у старшего оператора IP-телефон D-Link DPH-400S с гарнитурой Plantronics HW111N
• у остальных операторов софтфон CounterPath X-Lite с гарнитурой Plantronics Blackwire C210
• сеть обслуживается коммутатором D-Link DES-1210-28

Awesomium — это библиотека, для интеграции браузера на базе Chromium в своё приложение. Вся прелесть Awesomium состоит в том, что его можно интегрировать в приложение практически любого типа (есть примеры интеграции в 3D игры на базе Unity3D), он обладает широким набором возможностей для разработчика и, честно говоря, с ним просто приятно работать.

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

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

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

Seam carving это алгоритм для изменения размера картинки, сохраняющий важный контент и удаляющий менее значимый. Он был описан в статье S. Avidan & A. Shamir. Он дает лучший результат, чем обычное растягивание изображения ввиду того, что не меняет пропорций значимых элементов изображения. Две фотографии ниже демонстрируют работу алгоритма – исходное изображение имеет размер 332x480, в то время как модифицированное seam carving'ом 272x400.


В данной статье я опишу работу алгоритма используя псевдокод и код Matlab. Оригинал статьи, написанный мной на английском доступен тут, исходный код на гитхабе.

31 августа 2012 года японский математик Cинъити Мотидзуки опубликовал в интернете четыре статьи.

Заголовки были непостижимы. Объём был пугающим: 512 страниц в сумме. Посыл был дерзким: он заявил, что доказал abc-гипотезу, знаменитую, соблазнительно лёгкую числовую теорию, которая десятилетиями заводила математиков в тупик.

Затем Мотидзуки просто ушёл. Он не отправил свою работу в Annals of Mathematics. Он не оставил сообщение ни на одном сетевом форуме, которые часто посещают математики со всего мира. Он просто опубликовал статьи и ждал.

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

«А я такой: „Да, Гугл, мне это как бы интересно!“» – вспоминает Элленберг, – «Я запостил их в Фэйсбуке и в моём блоге, с пометкой: „Между прочим, похоже, что Мотидзуки доказал abc-гипотезу“».

Интернет взорвался. В течение дней даже далёкие от математики СМИ подхватили историю. «Решена сложнейшая в мире математическая теория», – объявила Telegraph. «Возможный прорыв в abc-гипотезе», – немного скромнее писала New York Times.

На математическом форуме MathOverflow математики со всего мира стали оспаривать и обсуждать заявление Мотидзуки. Вопрос, который быстро стал самым популярным на форуме был прост: «Кто-нибудь может объяснить философию его работы и прокомментировать почему она может пролить свет на abc-гипотезу?» – спросил Энди Путман, ассистент профессора в Университете Райса. Или, если перефразировать: «Я ничего не понял. Кто-нибудь понял?»

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

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

«Смотря на неё, ты чувствуешь будто читаешь статью из будущего или далёкого космоса», – написал Элленберг в своём блоге.

«Она очень, очень странная», – говорит профессор Колумбийского университета Йохан де Йонг, работающий в близких сферах математики.

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

Как профессор Мун Дучин из университета Тафтса выразила это: «Он воистину создал свой собственный мир».

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

Читая посты на Хабре, наткнулся на такой вопрос. В комментариях были предложены решения, но ни одно не подходило автору в виду накладных расходов на вызовы функций. И тогда я задумался, а действительно почему бы не использовать обычный switch, рассчитывая из двух параметров один хеш, который и использовать в switch. Но глянув на пример автора вопроса внимательнее я понял, что такой вариант просто так не пройдет, так как надо отлавливать default вложенных switch'ей.

Во многих языках программирования существует возможность объявлять объекты и переменные константными. И, соответственно, существуют рекомендации делать так, если Вы не собираетесь менять их значения. С приходом нового стандарта, в С++ появилась рекомендация возвращать объекты из функций по значению, потому что даже без RVO можно повысить производительность программы, за счет использования семантики перемещения. Что же будет, если использовать эти две рекомендации вместе: вернуть константный объект по значению? Попробуем разобраться далее.

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

Для более полного понимания этой статьи, рекомендуется прочитать ее первую часть, где основное внимание было уделено потокам и блокировкам, в ней объяснено много моментов (терминов, функций и т.д.), которые без пояснения будут использованы здесь.
В данной статье будут рассмотрены условные переменные…

В первой части этой статьи основное внимание будет уделено потокам и блокировкам в С++11, условные переменные во всей своей красе будут подробно рассмотрены во второй части…

Прочитал статьи про комбинаторную кодогенерацию на С++ в контексте линейного поиска в базе данных: Возможности оптимизации в языках C и C++ и Скорости разработки и исполнения не достижимые на С. Попробуем достигнуть скоростей разработки и исполнения на C?

После того, как я запустил компиляцию С++ кода из второй статьи, мне стало интересно — успею ли я написать аналог на С, который будет работать быстрее, пока код… компилируется? Не успел, код скомпилировался через 5 минут, а аналог на С писался все 15.

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

Постановка задачи

Один из алгоритмов, который я реализовывал, имел интересные особенности при работе с памятью:

• Могло выделяться огромное количество, до десятков и сотен миллионов небольших объектов одного типа.
• Объекты представляли собой POD- типы.
  
  POD

  A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.
• Заранее было неизвестно какое количество объектов понадобится, могло так случится, что потребуется сотня, а может и сто миллионов.
• Объекты никогда не удаляются по одному, в какой-то момент они становятся не нужны все сразу.
• Алгоритм хорошо распараллеливается, по этому выделением объектов занимается одновременно несколько потоков, по количеству ядер процессора(ов).

Использование в таких условиях стандартного new – delete приводит к очень большим потерям времени на удаление объектов. Если без отладчика удаление происходило хотя бы за несколько секунд, то в присутствии отладчика освобождение памяти замедляется примерно в 100(!) раз, и отладка проекта становится просто невозможной. Кроме того из-за большого количества выделенных объектов достаточно ощутимым становился перерасход памяти на внутренние данные распределителя памяти.
Для решения задачи выделения огромного количества объектов одного типа, и их пакетного удаления, был сделан lock-free контейнер MassAllocator. Код компилируется Visual Studio 2012. Полный код проекта выложен на github.

Эта статья является продолжением первой части и раскрывает технические подробности работы с «исполняемой спецификацией» с помощью SpecFlow.

Для начала работы вам понадобится плагин к Visual Studio (скачивается с официального сайта) и пакет SpecFlow (устанавливается из nuget).

Итак, наш Product Owner попросил команду разработать калькулятор…

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

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

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

Я надеюсь тут остались люди, которые помнят старый и ужасный на вид HabraPack? В последнее время я начал натыкаться на свои жуткие иконки на большом количестве сайтов и даже в терминалах оплаты местной компании, в разделе «Социальная сеть». Также, совсем недавно, знакомые попросили чуть обновить иконки, что я собственно и сделал.



Я буду обновлять иконки раз в день, большим количеством иконок. А пока можете СКАЧАТЬ и спокойно пользоваться, если вдруг найдутся люди, кому понравится.

.PSD файл прилагается.

В рамках своей диссертации «Модель прогнозирования по выборке максимального подобия» мне нужно было делать обзор моделей прогнозирования. Кроме обзора, я сделала вариант классификации, который мне тогда не очень удался. Классификацию уже немного поправила, теперь хочется разобраться в существующих моделях прогнозирования временных рядов. Такие модели называют стохастическими моделями (stochastic models).

По оценке некто Тихонова в его «Прогнозировании в условиях рынка» на сегодняшний день (2006 год) существует около 100 методов и моделей прогнозирования. Эта оценка звучит бредово, я полно разбирала ее! Давайте теперь вместе разберемся, какие же модели прогнозирования временных рядов существуют на сегодняшний день.

1. Регрессионные модели прогнозирования
2. Авторегрессионные модели прогнозирования (ARIMAX, GARCH, ARDLM)
3. Модели экспоненциального сглаживания (ES)
4. Модель по выборке максимального подобия (MMSP)
5. Модель на нейронных сетях (ANN)
6. Модель на цепях Маркова (Markov chains)
7. Модель на классификационно-регрессионных деревьях (CART)
8. Модель на основе генетического алгоритма (GA)
9. Модель на опорных векторах (SVM)
10. Модель на основе передаточных функций (TF)
11. Модель на нечеткой логике (FL)
12. Что еще?...

Предпосылки

В жизни любой крупной развивающейся компании рано или поздно встаёт вопрос о расширении возможностей телефонной станции и переходе от классической телефонии к IP.

Далёкой весной 2011 и перед нашей компанией встал такой вопрос, т. к. внешние и внутренние линии требуют постоянного расширения, а количество портов на старом Panasonic KX-TA624 было задано статично и расширению не подлежало. Открытие офисов в других городах и внедрение единой службы по работе с клиентами в других городах так же подталкивало к качественным переменам.

Техническое задание

Конечный продукт должен иметь следующие характеристики:
1) иметь большое количество (в нашем случае не менее 100) внешних и внутренних линий и быть готовым к расширению;
2) уметь приветствовать пользователей в рабочее время и сообщать о том, что они позвонили в нерабочее время, когда никого нет на месте;
3) таймауты переадресации при не ответе/занятости/недоступности должны настраиваться индивидуально;
4) должны быть предусмотрены очереди. Очередь — группа номеров, распределение звонков внутри которой происходит по определенным правилам;
5) записывать лог сообщений (как текстовый, так и аудио);
6) иметь гибкую политику распределения прав на внешние звонки. Должны быть предусмотрены пользователи, которые могут звонить только на внутренние номера; на городские номера; на любые номера;
7) в зависимости от времени суток, звонить на тот или иной номер.

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



Интересный метод, описан в статье «A Tutorial on Hidden Markov Models and Selected Applications in Speech Recognition» L.R. Rabiner, которая вводит модель скрытой цепи Маркова и описывает три ценных алгоритма: The Forward-Backward Procedure, Viterbi Algorithm и Baum-Welch reestimation. Несмотря на то, что эти алгоритмы представляют интерес только в совокупности, для большего понимания описывать их лучше по отдельности.