Сбор информации о беспроводных сетях или wardriving (в зависимости от способа передвижения, это может быть и warwalking, и warflying, и, как было продемонстрировано на BlackHat 2008 — warbalooning) занятие очень увлекательное и при этом предоставляющее богатые статистические данные об уровне защищености беспроводных сетей по городу.

Перепечатано с моего ЖЖ.

Решился написать про свой опыт изучения английского в экстремально короткие сроки (1 месяц) — вдруг кому пригодится. Также выдам немного инфы про то, как собеседовался за границу.

Статья получилась довольно объёмная, рассмотренные темы — форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

Форматы Ehternet фреймов.

1) Ethernet II

Рис. 1

Сколько мы ни говорим о необходимости использования флагов линкера и компилятора, нацеленных на идентификацию повреждений памяти и усложнения их эксплуатации — наши разработчики ДБО, АБС и различных сертифицированных продуктов, как правило, никак к этому не прислушиваются. И вот при написании pre-auth RCE server side exploit в очередной раз появилась идея написать об этом на основе наших последних работ.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1
Часть 2

Логарифмы

Если вы знаете, что такое логарифмы, то можете спокойно пропустить этот раздел. Глава предназначается тем, кто незнаком с данным понятием или пользуется им настолько редко, что уже забыл что там к чему. Логарифмы важны, поскольку они очень часто встречаются при анализе сложности. Логарифм — это операция, которая при применении её к числу делает его гораздо меньше (подобно взятию квадратного корня). Итак, первая вещь, которую вы должны запомнить: логарифм возвращает число, меньшее, чем оригинал. На рисунке справа зелёный график — линейная функция f(n) = n, красный — f(n) = sqrt(n), а наименее быстро возрастающий — f(n) = log(n). Далее: подобно тому, как взятие квадратного корня является операцией, обратной возведению в квадрат, логарифм — обратная операция возведению чего-либо в степень.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1

Сложность

Из предыдущей части можно сделать вывод, что если мы сможем отбросить все эти декоративные константы, то говорить об асимптотике функции подсчёта инструкций программы будет очень просто. Фактически, любая программа, не содержащая циклы, имеет f( n ) = 1, потому что в этом случае требуется константное число инструкций (конечно, при отсутствии рекурсии — см. далее). Одиночный цикл от 1 до n, даёт асимптотику f( n ) = n, поскольку до и после цикла выполняет неизменное число команд, а постоянное же количество инструкций внутри цикла выполняется n раз.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

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

Тем не менее, знание теории тоже имеет свои преимущества и может оказаться весьма полезным. В этой статье, предназначенной для программистов, которые являются хорошими практиками, но имеют слабое представление о теории, я представлю один из наиболее прагматичных программистских инструментов: нотацию «большое О» и анализ сложности алгоритмов. Как человек, который работал как в области академической науки, так и над созданием коммерческого ПО, я считаю эти инструменты по-настоящему полезными на практике. Надеюсь, что после прочтения этой статьи вы сможете применить их к собственному коду, чтобы сделать его ещё лучше. Также этот пост принесёт с собой понимание таких общих терминов, используемых теоретиками информатики, как «большое О», «асимптотическое поведение», «анализ наиболее неблагоприятного случая» и т.п.

Недавно я искал информацию об отличиях существующих VPN-технологий и наткнулся на эту статью. Здесь вкратце описаны преимущества и недостатки основных VPN, очень легко и доступно. Предлагаю сообществу перевод статьи.

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

Заметка про длину ключа шифрования

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

Сейчас почти невозможно найти VPN-шифрование с использованием ключа длиной менее 128 бит и все сложнее найти 256-битное шифрование в предлагаемых OpenVPN-решениях, ключи которых бывают даже 2048 бит. Но что означают эти цифры на практике, 256-битное шифрование действительно более безопасное, чем 128-битное?

Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.

Для чего нужен CMS

Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Продолжаем перевод цикла статей о внутренностях Питона. Если вы хоть раз задавались вопросом «а как же оно устроено?», обязательно читайте. Автор проливает свет на многие интересные и важные аспекты устройства языка.

В предыдущих частях мы говорили об объектной системе Питона. Тема ещё не исчерпана, но давайте пойдём дальше.

Когда я размышляю о реализации Питона, я представляю себе огромный конвейер, по которому движутся коды машинных операций, которые затем попадают в гигантский завод, где повсюду возвышаются градирни и башенные краны, — и меня просто переполняет желание подойти поближе. В этой части мы поговорим о структурах состояния интерпретатора и состояния потока (./Python/pystate.c). Сейчас нам нужно заложить фундамент, чтобы потом было легче понять, как исполняется байткод. Совсем скоро мы узнаем, как устроены фреймы, пространства имён и объекты кода. Но для начала давайте поговорим о тех структурах данных, которые связывают всё воедино. Учтите, я предполагаю наличие хотя бы поверхностного понимания устройства операционных систем и знания хотя бы таких терминов, как ядро, процесс, поток и т. п.

Во многих операционных системах пользовательский код исполняется в потоках, которые живут в процессах (это верно для большинства *nix-систем и для «современных» версий Windows). Ядро ответственно за подготовку и удаление процессов и потоков, а также за определение того, какой поток на каком логическом CPU будет исполняться. Когда процесс вызывает функцию Py_Initialize, на сцену выходит другая абстракция, интерпретатор. Любой Python-код, запускаемый в процессе, привязан к интерпретатору. Об интерпретаторе можно думать как об основе всех прочих концепций, которые мы будем обсуждать. Питон поддерживает инициализацию двух (и более) интерпретаторов в одном процессе. Несмотря на то, что эта возможность редко используется на практике, я буду её учитывать. Как было сказано, код исполняется в потоке (или потоках). Не исключение и виртуальная машина Питона (VM). При этом сама VM имеет поддержку потоков, т.е. у Питона есть своя абстракция для представления потоков. Реализация этой абстракции полностью полагается на механизмы ядра. Таким образом, и ядро, и Питон имеют представление о каждом из Python-потоков. Эти потоки управляются ядром и исполняются как отдельные потоки параллельно всем прочим потокам в системе. Ну… почти параллельно.

До сих пор мы не обращали внимания на слона в нашей посудной лавке.

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

В предыдущей части мы начали изучение объектной системы Питона: поняли, что именно можно считать объектом и каким образом объекты выполняют свою работу. Продолжим рассмотрение вопроса.

Приветствую вас в третьей части нашего цикла статей о внутренностях Питона (строго рекомендую прочитать вторую часть, если вы этого ещё не сделали, иначе ничего не поймёте). В этом эпизоде мы поговорим о важном понятии, к которому всё никак не подберёмся, — об атрибутах. Если вы хоть что-нибудь писали на Питоне, то вам доводилось пользоваться ими. Атрибуты объекта — это другие, связанные с ним, объекты, доступные через оперетор . (точка), например: >>> my_object.attribute_name. Кратко опишем поведение Питона при обращении к атрибутам. Это поведение зависит от типа объекта, доступного по атрибуту (уже поняли, что это относится ко всем операциям, связанным с объектами?).

В типе можно описать специальные методы, модифицирующие доступ к атрибутам его экземпляров. Эти методы описаны здесь (как мы уже знаем, они будут связаны с необходимыми слотами типа функцией fixup_slot_dispatchers, где создаётся тип… вы же прочитали предыдущий пост, так ведь?). Эти методы могут делать всё, что угодно; описываете ли вы свой тип на C или на Python, вы можете написать такие методы, которые сохраняют и возвращают атрибуты из какого-нибудь невероятного хранилища, если вам так угодно, вы можете передавать и получать атрибуты по радио с МКС или даже хранить их в реляционной базе данных. Но в более-менее обычных условиях эти методы просто записывают атрибут в виде пары ключ-значение (имя атрибута/значение атрибута) в каком-нибудь словаре объекта, когда атрибут устанавливается, и возвращают атрибут из этого словаря, когда он запрашивается (или выбрасывается исключение AttributeError, если в словаре нет ключа, соответствующего имени запрашиваемого атрибута). Это всё так просто и прекрасно, спасибо за внимание, на этом, пожалуй, закончим.

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

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

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

Как я и писал в предыдущем эпизоде (который, кстати, оказался успешным; спасибо всем, ваши просмотры и комментарии буквально заставляют меня двигаться дальше!) – сегодняшний пост посвящён реализации объектов в Python 3.x. Поначалу я думал, что это простая тема. Но даже когда я прочитал весь код, который нужно было прочитать перед тем, как написать пост, я с трудом могу сказать, что объектная система Питона… гхм, «простая» (и точно не могу сказать, что до конца разобрался в ней). Но я ещё больше убедился, что реализация объектов — хорошая тема для начала. В следующих постах мы увидим, насколько она важна. В то же время, я подозреваю, мало кто, даже среди ветеранов Питона, в полной мере в ней разбирается. Объекты слабо связаны со всем остальным Питоном (при написании поста я мало заглядывал в ./Python и больше изучал ./Objects и ./Include). Мне показалось проще рассматривать реализацию объектов так, будто она вообще не связана со всем остальным. Так, будто это универсальный API на языке C для создания объектных подсистем. Возможно, вам тоже будет проще мыслить таким образом: запомните, всё это всего лишь набор структур и функций для управления этими структурами.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Помимо изучения стандартной библиотеки, всегда интересно, а иногда и полезно, знать, как язык устроен изнутри. Андрей Светлов (svetlov), один из разработчиков Python, советует всем интересующимся серию статей об устройстве CPython. Представляю вам перевод первого эпизода.

Мой друг однажды сказал мне: «Знаешь, для некоторых людей язык C — это просто набор макросов, который разворачивается в ассемблерные инструкции». Это было давно (для всезнаек: да, ещё до появления LLVM), но эти слова хорошо мне запомнились. Может быть, когда Керниган и Ритчи смотрят на C-программу, они на самом деле видят ассемблерный код? А Тим Бёрнерс-Ли? Может он сёрфит интернет по-другому, не так, как мы? И что, в конце концов, Киану Ривз видел в том жутком зелёном месиве? Нет, правда, что, чёрт побери, он там видел?! Эм… вернёмся к программам. Что видит Гвидо ван Россум, когда читает программы на Python?

Пост обещает быть сверхкратким.

ExConsole позволяет встроить интерактивную консоль-отладчик в Python-приложение. Консоль вызывается при фатальном исключении либо по приему SIGQUIT (он же Ctrl-\).

Пример использования:

import exconsole
exconsole.register()

do_dangerous_stuff()

Пример работы с консолью:

Activating emergency console
----------------------------
Caused by:
ZeroDivisionError
integer division or modulo by zero

Stack frames:
  [  0] example.py:17

  [  1] example.py:15
              Tester().test()
  [  2] example.py:9
                  self.inner()
  [  3] example.py:6
                  self.divide(2, 0)
> [  4] example.py:3
                  return a / b
On frame 4
Source:
           def divide(self, a, b):
    >>         return a / b

Press Ctrl-D to leave console
Type "_help()"" for built-in commands

>>> print a,b
2 0
>>> _f(3)
On frame 3
Source:
           def inner(self):
    >>         self.divide(2, 0)

>>> print self
<__main__.Tester instance at 0x7f67c9a0e440>

Здравствуйте, дамы и господа. Сегодня мы рассмотрим, с помощью чего и как можно находить уязвимости в своих и чужих android-приложениях. Также увидим, что благодаря этим уязвимостям может сделать атакующий. Помимо этого, я приведу примеры уязвимостей, которые были найдены в рамках конкурса «Охота за ошибками» от компании Яндекс.

Добрый день!
В 2013 компания Cisco изменяет структуру сертификации по своим продуктам. 30 сентября закончится прием экзаменов ICND1 и ICND2, т.е. 640-822 и 640-816, а вместе с ними и общий CCNA. Таким образом, изменится ранжир статусов сертификации. Теперь CCNA превратится в CCNA Switching & Routing, а самым начальным и обязательным станет CCENT, т.е. новый ICND1.

Так раньше, чтобы получить CCNA Security необходимо было иметь действующий CCNA, теперь же достаточно CCENT (100-101) или Interconnecting Cisco Networking Devices Part 1 (ICND1) v2.0. Изменились и требования к знаниям, новый ICND1 значительно расширился.

Стоимость экзаменов осталась прежней.

Добрый день, уважаемые хаброжители!



Расскажу вам о своём проекте, который делаю в свободное время уже три года.

Работаю в компании занимающейся автоматизацией на должности программиста контроллеров. Последнее время, в основном, используем Siemens, ПЛК SIMATIC S7 и пакет визуализации WinCC, но есть опыт и по другим производителям. Профиль компании – нефтегазовый сектор (резервуарные парки, насосные, железнодорожные эстакады, причальные комплексы, системы пожаротушения).

Наверное, с самого первого проекта, меня интересовал вопрос тестирования программного обеспечения до этапа пуско-наладки на реальном оборудовании. Не так давно, на хабре был пост — Программирование ПЛК Siemens на Simatic Step7, и адреналин, про который говорилось в комментариях, знаком мне не понаслышке.

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

Добрый день, хабровчане! Полазив по Хабру, мною было обнаружено всего несколько топиков, в котором упоминалось бы словосочетание «Simatic Step 7». Хочу поделиться с Вами небольшой частью информации, накопленной мною за все время работы с программируемыми логическими контроллерами, и показать, что из себя представляют ПЛК, оболочка и что мне приходилось на них строить.

Данный пост содержит общую ознакомительную информацию о программировании ПЛК Siemens.

Время от времени, то здесь, то там, проскакивали новости о защищенных флешках с аппаратным шифрованием. Время шло, шило росло и вот однажды я понял — время пришло. Первым делом я открыл Яндекс Маркет и через расширенный поиск стал смотреть что предлагает нам рынок. Список предложений оказался всего на пару листов. По мере изучения специфики я выделял основные требования. Самым главным, пожалуй, становился вопрос работы без дополнительных программ с любой ОС. Таким образом почти все предложения моментально исчезли из поля зрения, так как большинство флешек, при подключении к ПК запускали встроенную программу с запросом пароля и дальнейшей расшифровкой контейнера. И как и следовало ожидать, такой подход работал только под windows. В итоге в поле зрения стали крутиться устройства с физической клавиатурой — ввел код, вставил в usb и работаешь. Яндекс предлагал только Corsair Flash Padlock 2. Но по многим параметрам безопасности он меня не устраивал. В поисках по интернету прилично удивил тот факт, что информации о подобного рода устройствах практически нет на русском языке. На хабре проскакивал пост о потрясающей флешке IStorage datAshur. Впечатляет. Но вот не задача. Такие устройства запрещены к продаже в России. Ebay, Amazon — поиск не дал нужных результатов. И тут мне на глаза попадается Aegis Secure Key. По виду и по описанию — один в один datAshur, только от другой компании. Ebay — результат 0, Amazon — результат положителен. 16Gb — 125$. Месяц ожидания, извещение, очередь, радость.