Недавний релиз jailbreak от Geohot'а для устройств на базе Apple A4 вызвал большой резонанс в кругах Dev Team. Большинство разработчиков упрекало Джорджа Хотца в эгоистичности его намерений, тщеславии и недальновидности. Почему же это произошло?

limera1n — untethered jailbreak от geohot использует вторую известную уязвимость в bootrom всех новых iOS устройств. Ранее, в сентября этого года, члены Dev Team pod2g и posixninja раскопали и частично документировали первую известную уязвимость в bootrom Apple A4 устройств. Теперь Apple известно о существовании обоих уязвимостей, которые, вероятно, будут закрыты со следующей аппаратной ревизией устройств.

Все дело в том, что bootrom (или SecureROM) — это небольшой загрузчик, который вызывается iPhone/iPad как только вы включаете устройство. Bootrom обычно прошит в read-only NAND (флеш-память), который прошивается на заводе при изготовлении устройства. Все последующие обновления iOS никак не затрагивают этот участок памяти: обновить bootrom возможно только с новой аппаратной ревизией устройств. Вот почему все найденные уязвимости в данном участке кода стратегически важны.

Не так давно большой интерес (1, 2) вызвала программа DroidSheep, перехватывающая аккаунты пользователей он-лайн сервисов, которые пользуются ими через общедоступный Wi-Fi. На исконно русский вопрос: «что делать?» кто-то предложит воспользоваться программами для защиты от подобного рода атак, написанными под Андроид. Вот их я и решил протестировать.

А тестировал я её давно (ещё в 2008 году) написанной мною программкой ARPBuilder, которая создавалась для проверки уязвимости различных МСЭ к ARP-спуфинг атакам (подробнее):



Собственно, мне удалось разыскать всего 2-х кандидатов на тесты: DroidSheepGuard и shARPWatcher (обе программы для полноценной работы требуют наличие root-доступа).

Об удачности атаки я судил по показаниям ARP-таблицы моего подопытного Android-устройства. Показания снимал через программку Net Status:

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

Причиной написания данной поста является то, что, как оказалось, можно преспокойно программировать под iOS полгода, и не знать полностью о жизненном цикле UIViewcontroller'ов. И на небольших проектах это даже получается. Однако, когда приходится иметь дело с серьезным, достаточно большим проектом, то появляются определенные проблемы с нехваткой памяти, «неправильной» и «непонятной» работой контроллеров, пропажей данных, и еще со многими типичными проблемами, о которых будет написано ниже.

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу

У одного молодого развивающегося провайдера на заре становления организации доступа для физ. лиц была принята следующая архитектура для сети:

• IPoE
• привязка порт-ip
• выдача адресов по DHCP (опция 82)
• маршрутизирующий сервер на Linux (CentOS)

По мере роста абонентской базы все проблемы из первых трех пунктов решались успешно. А с последним прогнозировались небольшие проблемы:

Передо мной возникла необходимость настроить резервное копирование на новом Linux-сервере, задачка эта оочень важная, но уж больно скучная: нужно написать и отладить скрипты, которые будут архивировать нужные папки (причем желательно делать инкрементальные архивы), базы данных, хранилища subversion, а затем переносить эти архивы на удаленный сервер. По этому я попробовал нагуглить готовое решение для этой задачки и в результате наткнулся на backup-manager — замечательный опенсорсный набор bash-скриптов, позволяющих:

• архивировать любые папки, в том числе и создавать инкрементальные архивы. В конфиге просто указывается список директорий, которые должны быть скопированы, а также «черный список» файлов, которые копироваться не будут.
• делать резервное копирование баз данных MySQL. В конфиге указываются логин и пароль mysql-юзера, имеющего доступ к базам, а всю остальную работу backup-manager делает сам.
• делать резервное копирование svn-репозиториев, причем бэкап делается не копированием папки с хранилищем, а с помощью команды svnadmin dump.
• шифровать архивы.
• копировать созданные архивы на удаленные сервера по FTP, SSH или (это самая важная для меня фича) в хранилище Amazon S3, а также записывать их на DVD.

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

На прошлой неделе настало событие важное (и даже жизнеопределяющее, готовое возыметь эффект на годы вперёд): решение Государственной комиссии по радиочастотам (ГКРЧ), принятое на заседании в четверг 8 сентября 2011 года. Если прочесть краткий отчёт о заседании, выложенный на сайте Минсвязи на следующий день (9 сентября), то явствуют вот какие основные новости:

• В России будет не более семи операторов LTE, для которых выделена полоса частот от 791 до 862 МГц.
   
• Операторы LTE будут определены на конкурсной основе: четверо победителей конкурса получат право построить двухдиапазонные сети, а трое остальных — однодиапазонные в верхнем диапазоне.
   
• Выделение частот обусловлено обязательством оператора совершить конверсию частоты (за свой счёт убрать из этого диапазона передатчики — например, военные), взамен оператору гарантируется право эксплуатировать диапазоны, которые он очистил.
   
• О возможности употребления LTE в полосах радиочастот действующих операторов было принято решение завершить проведение исследований и представить в I квартале 2012 года в ГКРЧ предложения. То есть такого LTE не будет ещё, по меньшей мере, полгода.

Если на этом месте остановиться, то можно немного (и небезосновательно) порадоваться тому, что дело наконец подвинулося с мёртвой точки; однако достаточно подняться и двинуться дальше, читая сообщения в прессе и задаваясь даже самыми простыми вопросами («Кому выгодно?», «Как это будет?»), как наткнёшься на ряд неприятных новостей и немного противоречивых истолкований произошедшего.

Модуль полностью нативный и написан Игорем Сысоевым, анонс был вчера:

Изменения в nginx 1.1.3 14.09.2011
*) Добавление: модуль ngx_http_mp4_module.

Только что я его поставил и он работает.
Основная директива mp4 совместима с модулем h264.code-shop.com/trac/wiki/Mod-H264-Streaming-Nginx-Version2
Описание директив модуля:
nginx.org/en/docs/http/ngx_http_mp4_module.html

Ссылка на исходник, спасибо powder96
nginx.org/download/nginx-1.1.3.tar.gz
Ссылка на rpm для Centos 5
centos.alt.ru/?p=579

По моему это просто чудо какое то.
Добейте если не жалко 22 плюса к новости до инвайта.

В одном из наших свежих проектов команде разработчиков была поставлена задача собрать максимально реальные контактные данные о пользователях нашего сайта. Жаркое обсуждение правильных и неправильных форм регистрации, одно- и двушаговые, дополнение информации по мере пользования сайтом… Казалось поток идей не остановится. Однако ни одна из них не гарантировала, что в результате мы не получим кучу никчемных данных. Валидировать? Можно, но разве все предусмотришь? Активация учетной записи через почтовый ящик для его валидации? Но куча сервисов типа 10 Minute Mail сводят на нет эффект. К тому же, специфика проекта не позволяла слишком растягивать процесс регистрации. Решено было, что пользователь должен зайти, сделать своё дело, а потом уже активировать или нет свою учетную запись. В конце концов прозвучала фраза «А давайте активировать по SMS!». Поиск провайдеров, изучение прайс-листов и отказ от идеи взвалить обработку SMS на стороннюю контору… Стало понятно, что принимать и обрабатывать их придется самим.

Так же как и в топике — «О блоках и их использовании в Objective-C часть 2-ая», мы продолжим говорить о преимуществах использования блоков на живых примерах.
Здесь мы рассмотрим удобства использования блоков при управлении последовательностью операций.

5. UIView анимации, последовательность анимаций.

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

Что делать, если нужно создавать много Word файлов одинакового вида, но разного содержания? Например заполнять бланки, квитанции.

Есть 3 варианта:
1) использовать одну из библиотек для работы с Word документами
2) сохранить документ в формате docx, открыть архиватором и внутри мы увидим "\word\document.xml" — чистый xml, с которым можно работать через str_replace (спасибо Enuriru за подсказку)
3) использовать сторонний сервис, который сделает за меня большую часть работы

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

Второй варинт хорош и прост, когда мы работаем с word документами в формате .docx, но к сожалению он не поддерживает формат .doc

В процессе проработки третьего варианта, наткнулся на интересное решение LiveDocx

Преимущества:
— файл шаблона можно создать привычным способом через Word
— представление документа в форматах doc, docx, rtf, pdf
— не нужно заморачиваться с представлением Word документа через html или XML
— простота подключения
— надежность — сервис существует давно и под него даже есть готовая библиотека от Zend
Недостатки:
— в бесплатной версии ограничение на 250 генерируемых документов в сутки
— шаблон нельзя менять (например нельзя сгенерировать таблицу с кол-вом строк, равным количеству элементов в базе)

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

Как можно достичь этих двух противоположных целей?