В комментарии к статье про dVHD заморозку системы я намекнул на быстрый способ распространения/синхронизации больших файлов по локальной сети.

Конкретно, в моем случае VHD файл весил примерно 120 GiB, и его нужно было залить на 30 PC. При каждом обновлении VHD он перезаливался. Под катом читайте историю, про то, как с таким большим файлом не справлялся BTSync, и про создание RingSync.

Начну с небольшого QA (Вопрос-Ответа), сравнивая различные схемы обмена данными.

Классика: Server → Client

Q: Что происходит в классическом варианте, когда один сервер раздает файл множеству клиентов?

A: Допустим, что и на сервере и на клиентах установлены обычные HDD (последовательное чтение/запись выполняется быстро, произвольное - медленно).

У нас есть:

• 1 сервер (файловое хранилище);
• 4 клиента (загружающие с файлового хранилища один и тот же файл);
• 1 switch (все порты работают в дуплексном режиме; скорость соединения на всех портах одинаковая).

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

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

В итоге скорость загрузки упадет в 4 раза, по сравнению со случаем, когда только 1 клиент загружает файл. Чем больше клиентов, тем меньше скорость загрузки у каждого из этих клиентов. Для 30 клиентов и 100 Mbps сети 120 GiB файл будет загружаться минимум 3 дня 13 часов и 54 минуты, т.е. для клиента 100 Mbps превратятся в 3 Mbps :( .

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

1. Все клиенты запустили загрузку файла в одно и то же время.
2. Запуск загрузки не был синхронизирован, например, получился разброс ±10 минут.

Вспомним, что у нас обычные HDD, которым трудно дается произвольный доступ к данным...

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

Во втором случае клиенты станут обращаться к разным частям, и у системы будет меньше шансов повторно воспользоваться кешированными частями файла. Для HDD это будет выглядеть как произвольный доступ к данным. Например, второй клиент запустил загрузку с 10 минутным отставанием от первого клиента, значит, первый клиент уже успел загрузить 7 GiB, и чтобы система смогла отдавать части файла для второго клиента без повторного обращения к HDD, ей нужен кеш размером в 7 GiB.

В реальности 100% “попадание” в файловый кеш не требуется, например, в кеш можно помещать не только текущую часть файла, но и несколько следующих частей...

P2P: BTSync

Q: В чем заключается польза от использования p2p в локальной сети?

A: Если p2p клиенты используют следующую схему передачи данных:

1. сид отправляет каждому пиру разную часть файла,
2. каждый пир пересылает полученную часть файла другому пиру,
3. сид отправляет каждому пиру разную часть файла, которую сид не отправлял никому ранее,
4. одновременно с предыдущим пунктом, пиры продолжают обмениваться частями файла,
5. пункты 3-4 повторяются, пока сид не раздаст все части файла, и все пиры получат эти части

, и все они подключены к одному switch'у, то, теоретически, скорость получения данных пиром не будет уменьшаться с увеличением числа пиров (в классическом варианте Server → Client скорость уменьшалась). Это работает благодаря возможности switch “соединять” любые 2 своих порта, и данные между этими портами смогут передаваться на полной скорости соединения.

Похожий режим работы в BitTorrent клиентах называется Super-seeding.

Q: Какой может быть негативный эффект от использования этой схемы?

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

История про BTSync и большой файл

Про BTSync написано уже много статьей ( 1   2   3 ), но самое интересное можно было найти на официальном форуме (он переехал сюда). Вкратце, баги были, и с ними приходилось бороться, например, в некоторых версиях были проблемы с Local Peer Discovery (не всегда работал) - обходилась проблема прописыванием IP одного из пиров в сети. У него есть еще тележка интересных “особенностей”, но сейчас речь пойдет про его работу с большими файлами...

Для развертывания системы на VHD, был собран минимальный WinPE, содержащий:

• BTSync - запускался через “BTSync.exe /config config.json”;
• программу ShowWindow, которая используя FindWindow, SendMessage (WinAPI), и переданное ей имя класса окна “BTSync4823DF041B09”, открывает скрытое окно BTSync (он запускается “свернутым в трей”, а трея у нас нет...);
• драйверы (в основном для NIC);
• скрипты (startnet.cmd: тюнинг сетевого стека, вызов пред и пост разверточных скриптов).

Всё это происходило в середине 2014 года (или 2013...), и пишется по памяти⁴.

На сиде BTSync запускался с RW секретом, а на пирах - с RO секретом (с включенной опцией принудительной синхронизации, если файл существует, и отличается от файла у сида).

После трех “разворачиваний” системы по 8-10 PC за раз (скорость сетевого соединения 100 Mbps; PC подключены к одному switch; максимальная скорость HDD была в районе 110 MiBps; размер файла тот же - 120 GiB), собралась следующая “статистика”:

• после запуска BTSync на всех PC, и начала синхронизации, в районе часа сетевая активность была минимальна, т.е. файл не передавался;
• на некоторых (1-2) пирах процесс синхронизации прерывался, и приходилась вручную перезапускать BTSync;
• при подключении через нормальный switch средняя скорость загрузки была 8 MiBps (падала до 6, поднималась до 9) - при отключенном шифровании трафика;
• при подключении через устройство, очень похожее на ZyXEL ES-116S, средняя скорость загрузки была 3.4 MiBps (иногда поднималась до 6) - шифрование трафика также было отключено.

Эксперимент 1

После этого было решено провести эксперимент: взять 2-3 PC, нормальный  switch, и добавить Process Explorer в WinPE для наблюдения за активностью  BTSync. Судя по описанию проблем на форуме - у каждой версии имелся свой набор “особенностей” (новая версия не значит более лучшая версия), поэтому в эксперименте участвовало несколько версий BTSync (1.0.134 - 1.3.106). После каждого опыта, скаченный пирами файл стирался, и все PC перезагружались.

• И так, запускаем BTSync на сиде, запускаем на одном пире, и вуаля: сетевая активность появляется сразу же, и файл синхронизируется со скоростью 11 MiBps.
• Теперь сделаем то же самое, но запустим два пира одновременно: сетевая активность минимальна, у сида наблюдается высокая дисковая активность (BTSync запустил подсчет контрольных сумм частей файла?), и только после уменьшения дисковой активности начинается синхронизация с некоторыми “особенностями” (про них - ниже).
• А если взять первый вариант, и запустить второго пира посередине синхронизации: синхронизация приостанавливается, и возрастает дисковая активность у сида (вычисляет контрольные суммы?), затем (когда вычислит все контрольные суммы?) синхронизация продолжается (опять же с “особенностями”).

Особенности синхронизации заключались в том, что при каждом новом запуске, схема работы отличалась от предыдущего запуска. Всего получилось 3 схемы работы (сокращения: сид - s, пир1 - p1, пир2 - p2):

1. s --{7 MiBps}--> p1; s --{4.5 MiBps}--> p2; p1 --{7 MiBps}--> p2; p2 --{4.5 MiBps}--> p1; через определенный промежуток времени p1 и p2 меняются местами:
   s --{7 MiBps}--> p2; s --{4.5 MiBps}--> p1; p2 --{7 MiBps}--> p1; p1 --{4.5 MiBps}--> p2; смена происходит с определенным периодом времени;

2. s --{10 MiBps}--> p1; после того, как p1 все загрузит:
   s --{10 MiBps}--> p2;

3. s --{7.5 MiBps}--> p1; s --{3.5 MiBps}--> p2; p1 --{7.5 MiBps}--> p2; p2 --{3.5 MiBps}--> p1; затем:
   s --{4.5 MiBps}--> p2;                        p2 --{4.5 MiBps}--> p1; и возвращение:
   s --{7.5 MiBps}--> p1; s --{3.5 MiBps}--> p2; p1 --{7.5 MiBps}--> p2; p2 --{3.5 MiBps}--> p1; смена происходит с определенным периодом времени.

Причем первая схема работы (самая лучшая) включалась, когда BTSync на обоих пира запускался одновременно. Если же была задержка между запусками, то чаще встречалась схема 3 или 2.

Что касается различий в версиях BTSync, то в опытах с более новыми версиями второй вариант схемы встречался реже. Но это ничего не значит, т.к. испытания каждой версией повторялись всего 4 раза, что очень мало. Версии 1.0.134 и 1.3.106 испытывались большее число раз.

Однако в новых версиях (предположительно начиная с 1.3. x), появилась еще одна “особенность”: когда размер загружаемого файла (можно посмотреть командой dir в консоли) на пире достигает 70% (или около того), рост размера файла приостанавливается на некоторое время.

Эксперимент 2

За основу брался первый эксперимент, с отличиями:

1. использовалась только последняя версия BTSync;
2. загруженный пирами файл не удалялся, а изменялось его содержимое.

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

:( :(

В повседневном использовании с 1 GiB файлами мне помогала "легкая приостановка" - через контекстное меню “иконки в трее” пира поставить BTSync на паузу, а затем убрать паузу.

RingSync

Во время борьбы с “особенностями” BTSync появились несколько мыслей:

• большинство проблем с BTSync связаны с теми возможностями, которые в данном случае не нужны;
• нам не нужно отслеживание изменений в файле, т.к. каждый раз его все равно приходится передавать целиком, и источник всегда один - сид;
• следовательно, нет необходимости в отдельном этапе подсчитывания контрольных сумм, и определения “кто из пиров обладает более новой версией файла”;
• у нас всего один файл;
• HDD попросил сделать последовательное чтение/запись файла 8-O .

С этими мыслями родилась следующая схема:

1. сид передает часть файла пиру;
2. пир сохраняет ее на HDD, и параллельно передает следующему пиру (то же самое делают остальные пиры в цепочке);
3. лич (последний пир) просто сохраняет часть файла на HDD.

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

От switch здесь требуется всего лишь “соединить” Rx одного порта с Tx другого порта на полной скорости (см. схему), с чем он отлично справляется.

Программа на Golang

На современном языке сделать PoC этой схемы не составит никакого труда. На Golang основную часть программы пира можно записать всего в одну строчку:

io.Copy(io.MultiWriter(outFile, peerConn), seedConn)

, все остальное - обвязка.

Последовательность запуска

Код RingSync написан максимально просто, и при этом в нем предусмотрена возможность запуска сида и пиров в произвольном порядке. Что это означает? Можно одновременно запустить всех пиров и сида, дождаться пока они включатся, а затем запустить лича. Именно лич запускает процесс синхронизации.

Под капотом это выглядит так:

1. запускаются пиры и лич, и начинают слушать входящие соединения;
2. запускается лич, и устанавливает соединение с последним пиром;
3. каждый пир устанавливают соединение с предыдущим пиром (по цепочке);
4. первый пир устанавливают соединение с сидом, и сид начинает отправку данных.

Если немного пожертвовать простотой, и добавить возможность переподключения при неудачной “установке соединения”, то можно будет и лича, и сида, и пиров запускать в любой последовательности.

Репозиторий

RingSync можно форкнуть здесь.
Там же можно скачать уже собранный для Windows 32bit бинарник.

Q: Почему именно Windows 32bit?
A: Потому, что я его использовал с WinPE 32bit. К тому же, вместе с RingSync лежит специальный launcher, который облегчает конфигурирование после сетевой загрузки. Launcher считывает конфиг из файла (одного и того же для всех PC), и в зависимости от MAC-адреса первого сетевого интерфейса PC, настраивает этот сетевой интерфейс, и запускает RingSync с нужными параметрами. Сейчас launcher завязан на использование netsh, поэтому результат кросс-компиляции под не Windows работать не будет. В отличие от launcher, у самого RingSync таких проблем нет :)

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

Сид (слушает порт 5001, ожидает подключения от лича/пира с IP “192.168.0.2”, рассылает содержимое файла “big_file.vhd”):

RingSync -mode=seed -port=5001 ^
         -leech=192.168.0.2 -if=big_file.vhd

Пир (слушает порт 5001, ожидает подключения от лича/пира с IP “192.168.0.3”, подключается к порту 5001 сида/пира с IP “194.168.0.1”, записывает полученные данные в файл “big_file.vhd”):

RingSync -mode=peer -port=5001 ^
         -leech=194.168.0.3 ^
         -seed=194.168.0.1:5001 -of=big_file.vhd

Лич (подключается к порту 5001 сида/пира с IP “194.168.0.1”, записывает полученные данные в файл “big_file.vhd”):

RingSync -mode=leech ^
         -seed=194.168.0.2:5001 -of=big_file.vhd

Сборку этих же строк можно увидеть в исходниках launcher'а.

TCP Congestion Control

До написания кода RingSync была идея собрать свой TCP-велосипед, в котором данные передавались бы по цепочке от сида -> через пиров -> к личу, а ответ (ACK), подтверждающий получение данных, отправлял бы лич к сиду. Причем, если сида переименовать в “сервер”, лича - в “клиент”, а пиров в “маршрутизаторы”, то получится типичная схема передачи данных в Интернете. Вот только маршрутизаторы не сохраняют переданные через себя данные. В этот TCP-велосипед, можно было бы включить наиболее подходящий для данных условий передачи данных TCP Congestion Avoidance Algorithm ( 1   2   3 ), а не полагаться на системный TCP Congestion Control и его настройки. А в будущем можно было бы получить больший контроль над передачей данных, например, добавив возможность отправки сообщений о “заторах” в сети или HDD.

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

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

Это напоминает движение длинного состава (локомотив-сид тянет спереди) с большим числом вагонов (пиров), и пружиной (буфером) вместо сцепки.

На самом деле второй вариант даже лучше, т.к. для некоторых алгоритмов TCP Congestion Avoidance (косвенно это влияет и на остальных) чем меньше RTT - тем лучше. А в первом варианте мы заведомо создаем более неблагоприятные условия...

В итоге, второй вариант, даже в сети с двумя switch:

switch{1 Gbps}[сид -> пир -> пир]
└─{100 Mbps}—↓
switch{100 Mbps}[пир -> пир -> пир -> лич]

показал стабильные 11.8 MiBps.

PC подключены к разным switch

В сети с несколькими switch узким местом может стать соединение между ними. Например, если строить цепочку пиров в произвольном порядке, то при сети:

switch1{1 Gbps}[сид, пир2, пир4, пир6]
└─{1 Gbps}─┐
switch2{1 Gbps}[пир1, лич, пир3, пир5]

, и цепочке:

сид->пир1->пир2->пир3->пир4->пир5->пир6->лич

, скорость упадет в 4 раза.

Q: Почему скорость падает в 4 раза? Как получилось это число “4”?
A: Если возьмем все потоки данных в направлении от switch1 к switch2, то получим:

1. сид  -> пир1
2. пир2 -> пир3
3. пир4 -> пир5
4. пир6 -> лич

Теперь посмотрим на потоки данных в обратном направлении (от switch2 к switch1):

1. пир2 <- пир1
2. пир4 <- пир3
3. пир6 <- пир5

В направлении от switch1 к switch2, общий канал в 1 Gbps делили 4 потока, получая максимум 0.25 Gbps на поток. В обратном направлении получилось 3 потока, соответственно максимум 0.33 Gbps на поток. Самым узким местом стал канал от switch1 к switch2 (максимальная скорость потока 0.25 Gbps). В самом узком месте скорость потока в 4 раза меньше, по сравнению с максимальной скорости в “самом широком месте” (1 Gbps).

Q: Как исправить ситуацию?
A: Достаточно строить цепочку примерно так (можно сразу перейти к TL;DR) 8) :

1. добавить в цепочку сида;
2. взять switch, к которому подключен сид, и добавить в цепочку всех пиров (в любом порядке), подключенных к этому switch;
3. взять следующий, ранее не взятый, switch (к которому подключены пиры), подключенный к предыдущему switch (возможно не прямое подключение, а подключение через несколько промежуточных switch, к которым не подключен ни один пир), и добавить в цепочку всех пиров (в любом порядке), подключенных к этому switch;
4. повторять предыдущий пункт, пока он будет выполним (“следующий switch” будет существовать);
5. если можно вернуться к предыдущему switch, то вернуться к нему, и выполнить предыдущий пункт;
6. последнего пира в цепочке назвать личем.

TL;DR: используем обход графа в глубину, при этом:

• вершины - это switch;
• в вершине хранится список пиров, подключенных к этому switch/вершине;
• начинаем со switch/вершины, к которому подключен сид;
• при входе в вершину, добавляем в цепочку всех пиров из списка этой вершины.

Для использования этого способа нужна информация о топологии сети на канальном уровне.

Ссылки «в тему»

• Project Iris - Completely decentralized cloud messaging
• Filesync ( Golang : (
• Недостатки TCP и новые протоколы транспортного уровня
• Catapult - Fast Data Transfers
• Pulse - free (as in freedom), secure, and distributed file synchronization engine
• Фильм Unstoppable 2010 + сдвинуть тяжелый состав ("Интересный факт" про сцепку; подробнее)

Как обойтись без копирования большого VHD файла по сети?

На самом деле можно не копировать каждый раз полный VHD при обновлении системы, а распространять только dVHD с обновлением. Такая схема обновления работает следующим образом (система обновляется на одном Master-PC, и копируется на множество Slave-PC):

• На Master-PC все изменения, в ходе обновления системы, сохраняются в новый dVHD файл.
• Все Slave-PC должны хранить оригинальный VHD файл с Master-PC, поэтому на них нужно создавать дополнительный dVHD файл, в котором будут сохранены все отличия Slave-PC от Master-PC. Без этого следующий пункт работать не будет.
• На Slave-PC копируется dVHD файл с обновлением, и, затем, объединяется с VHD файлом (если бы VHD файл на Master-PC и Slave-PC отличался, то объединение завершилось бы с ошибкой).
• На каждом Slave-PC заново создается тот дополнительный dVHD файл, хранящий отличия каждого Slave-PC от Master-PC.
• На Master-PC dVHD файл с обновлением системы также объединяется с VHD файлом.

При этом время распространения обновления будет включать в себя время копирования обновления на Slave-PC + время объединения VHD с dVHD. Здесь важно, чтобы объединение выполнялось быстро, иначе суммарное время (копирование dVHD + объединение) может превысить время простого копирования цельного VHD файла. Еще один минус – из-за появления на Slave-PC дополнительного dVHD файла, система будет работать медленней.

Это уже второе описание истории про то как несколько людей организовывало PHDays Everywhere in Omsk и OmskCTF.

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

Несколько ссылок: пресс-релиз мероприятия, событие в G+, VK, Фотки (если их смотреть в режиме слайд-шоу и читать подписи, то получится небольшая история; не забывайте нажимать на зум/лупу на верхней панели - фото загрузится в оригинальном качестве).

Мы уже четвертый год организовываем PHDays Everywhere в Омске, и в отличие от предыдущих лет решили провести мероприятие на более высоком уровне - арендовали большой зал на два дня, увеличили количество Geo‑квестов. У самих же квестов в этом году появилась история - они рассказывают про секреты нано-государства Brizzland...

Подготовка

За полтора месяца до часа X

Начинаем накидывать задачи в Trello.

Как выглядит Trello сейчас.

Одна из первых задач звучала примерно так: “Разнообразить квесты DarkNet'ом”, с описанием “Перенести часть описаний задач в DarkNet”. Предполагалось, что участники вначале задания получат адрес сервиса в DarkNet'е, а затем, открыв этот сервис, получат само описание задания.

Среди кандидатов на “роль DarkNet” были (не все из них истинные DarkNet):

1. .onion (Tor)
2. i2p
3. Bitmessage
4. Project Maelstrom
5. BTSync
6. Synthingc
7. ZeroNet
8. Perfect Dark

Сеть должна была удовлетворять нескольким требованиям:

1. обход NAT (при работе по IPv4) - отсеялись Project Maelstrom, ZeroNet, и Perfect Dark;
2. односторонняя авторизация - отсеялся Synthingc.

В итоге остались:

1. .onion (Tor)
2. i2p
3. Bitmessage
4. BTSync

Теперь нужно было дать ответ на вопрос “Как участники поймут, что сервис нужно искать в особой сети?”.

С “.onion” и “.i2p” проблем не было - сеть можно определить по домену.

С Bitmessage было труднее - намеком на Bitmessage могло служить только начало идентификатора пользователя “BM-”.

С BTSync дела были еще хуже - видимые маркеры в идентификаторе сервиса отсутствовали. Решение проблемы оказалось простым - вместе с адресом сервиса, участник сразу же получает клиента для используемой в задании сети. Но и здесь участников ждал сюрприз.

BTSync

В некоторых старых версиях BTSync, при создании сервиса под старой Windows (NT5.*), возникал баг - генерировался секрет невалидный для других ОС. В новых версиях этот баг устранили, и все клиенты начали корректно воспринимать невалидный секрет.

Для воспроизведения этого бага в задании, участники получали “(не)валидный” секрет + старую версию BTSync, в которой был баг. Если просто воспользоваться полученным секретом и клиентом BTSync, то он покажет сообщение “This secret is invalid. Please generate a new secret or enter a secret generated at another computer”.

Быстро обойти баг можно было двумя способами:

• [простой] скачать новую версию BTSync
• [сложнее] запустить BTSync на аналогичной старой Windows

Bitmessage

В Bitmessage также было несколько уловок.

Если оба участника переписки расположены за разными NAT, то сообщения в Bitmessage распространяются очень медленно. Поэтому участники получали не обычный идентификатор пользователя, а идентификатор (и имя) chain'а.

Одним из участников chain'а был бот, с которым участникам нужно было сыграть в игру, чтобы получить описание задания. При этом вся переписка chain'а доступна всем командам, подключившимся к этому chain'у. Первая команда, которая “выбьет” из бота описание задания откроет его также и для всех остальных команд.

Чуть позже от игры с ботом пришлось отказаться - слишком долго приходят сообщения. Сам бот стал выполнять роль простого Custom Message эхо-сервиса.

Игра с “заклинившим ботом”

И все же, от идеи “игры с ботом” отказываться не хотелось, поэтому игра с “заклинившим ботом” встречала участников в .onion сети.

Игра была простой. При подключении к “заклинившему ботоу” - тот несколько раз отправлял одно и то же слово, после чего разрывал соединение. Участник должен был отправить боту это слово, тогда бот перешлет участнику ссылку на описание задания в вперемешку с “заклинившим словом”:

Cookie | URI

Cookie | URI double2

NOW!

Protection

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

За месяц до часа X

Обычно к этому моменту уже приходят письма-анкеты от PT, в которых нужно указать информацию о своем хакспейсе. Затем эта информация публикуется на сайте, в разделе PHDays Everywhere.

Мы уже стали волноваться, т.к. письмо-анкета до сих пор не пришла, и нас не было в списке хакспейсов. Связаться получилось только 5-го мая, и информация о хакспейсе была успешно отправлена (правда на сайте мы появились только перед самим началом PHDays - после 16 мая).

В этом году мы решили провести PHDays Everywhere в большом зале новой библиотеки ОмГТУ, которая чем то напоминает коворкинг. Так как это была библиотека, то мы не могли упустить шанс, и сделали Old School geo-квест с участием книг (о нем дальше). А вот делать geo-квесты с IP-камерами мы изначально не планировали, но вскоре это изменилось...

За две недели до часа X

Для OmskCTF, как и в прошлом году, мы хотели взять задания от PT, добавить свои задания, и объединить это все в квесты. Наши планы изменило письмо:

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

Онлайновый конкурс: площадки могут участвовать в экономической жизни созданного для PHDays государства United States of Soviet Unions (USSU)...

В этот момент стало понятно, что квесты с IP-камерами все же нужны. Как и в прошлом году, нам одолжили несколько резервных камер, используемых в университете, фирмы ***. В этих квестах предполагалось, что участникам предстоит взломать камеры для получения изображения с них (логин/пасс участником не был известен). Камеры были той же фирмы, что и год назад, но с более новой версией прошивки. За 30 минут поиска уязвимостей мы нашли 0 новых уязвимостей, а старые дыры были залатаны.

Так как, в этот раз, лежащие на поверхности уязвимости отсутствовали, то можно назвать производителя камер - это был Hikvision, а модель камер в этом году - DS-2CD2032-I.

Раз простые уязвимости “от производителя” отсутствуют, то добавим свои :) Время поджимало, поэтому просто сделали аналог прошлогодней уязвимости с возможностью анонимного входа в web-интерфейс камеры.

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

Для начала, мы подключились к камере по telnet/ssh, и осмотрелись. Вскоре поняли, что постоянное хранилище примонтировано в “/dav/”. В директории “/dav/” располагался скрипт “initrun.sh”, который инициализировал систему, и распаковывал файлы из лежащих рядом архивов.

Теперь нужно было понять какой из архивов содержит файлы web-интерфейса. После беглого осмотра инициализирующего скрипта, архив был найден, им оказался “IEfile.tar.gz”. Название архива буквально намекало, что web-интерфейс создавался специально под Internet Explorer, а под остальными браузерами ждите глюков.

Архив уже нашли, осталось найти способ выгрузить его из камеры, а затем (после правки) загрузить обратно. На одном из форумов использовали для этого комады/бинарники ftpput и ftpget, присутствующие в прошивке 5.1.2. Однако, на DS-2CD2032-I была более новая версия прошивки, в которой ftpput и ftpget отсутствовали. На помощь пришел “/bin/rz” - ZMODEM (под win наиболее стабильный клиент - Tera Term), при помощи которого можно будет залить измененный “IEfile.tar.gz”. А для выгрузки использовался работающий http сервер - нужно было всего-лишь выполнить команду:

cp /dav/IEfile.tar.gz /home/doc/

и загрузить “http://192.0.0.64/doc/IEfile.tar.gz”.

В этот момент планы претерпели изменения. Вместо замены оригинального “IEfile.tar.gz” - сделали следующее:

echo cp -Rf /dav/IEfile_patch/\* /home/ >> /dav/initrun.sh

Теперь достаточно записать отдельный измененный файл в “/dav/IEfile_patch/”, сохранив при этом относительные пути (из “IEfile.tar.gz”). При включении камеры все пропатченные файлы из “/dav/IEfile_patch/” заменят собой оригинальные файлы из “IEfile.tar.gz”.

Чтобы вернуть все назад (а это придется сделать по завершению PHDays) достаточно будет очистить директорию “/dav/IEfile_patch/”.

Немного про задания с камерами

Всего было два задания с камерами: First Eye и Second Eye. В обоих заданиях камеры были спрятаны внутри шкафчика для вещей. Сами шкафчики расположены у входа в библиотеку.

Second Eye

Изначально задание было простым:

• Флаг записывается в QR-код, и наклеивается на стенку одного из шкафчиков.
• Камера через дырочки в дверце шкафчика “видит” окружающую обстановку.
• Участник получает IP камеры, и ключи от нескольких шкафчиков. Изначально каждый ключ имеет брелок с номером шкафчика. В этом задании брелки с ключей были сняты.
• Для “захвата флага” участнику нужно было:
  1. по изображению с камеры (и полученным ключам) понять где она находится;
  2. прогуляться до шкафчиков;
  3. наблюдая за собой на изображении с камеры, найти конкретный шкафчик; перебирая ключи открыть шкафчик;
  4. считать QR-код.

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

Во время изучения камер, мы заметили, что, при включении ИК-подсветки, с изображения камеры пропадают все надписи на бумаге, сделанные обычной ручкой. При этом камера продолжает “видеть” текст, распечатанный на лазерном принтере черным тонером.

В этот момент родился новый сценарий задания:

• Участник получает IP:port камеры и подсказку “if you only look where you can't go, you will miss the riches below”.
• Получив доступ к изображению с камеры, участник наблюдают окружающую обстановку через отверстие в шкафчике:

IP Cam See

• Также на OSD камеры выводится подсказка: “librarians have a keys for the secret place - barter appropriate”.
• Участники обменивают что-нибудь на коробку с ключами:

Box + Keys

• Находят шкафчик.
• Перебирает ключи (всего 9 ключей).
• Открывают шкафчик, а внутри - печенья с предсказанием.
• Разламывают печеньку - там конец флага: “_now_you_see_me”:

End Of Flag

• Вспомнив ранее полученные подсказки, и “повертев” коробку от ключей, участник подносит коробку к камере (“козырьком вверх”, чтобы закрыть свет) и получает вторую часть флага:

In Box - Malevich's black square || Bottom Box - Eye

True

Позже сценарий еще раз изменился. ИК-подсветка засвечивала дверцу, и через отверстие в дверце камера ничего не видела (отверстие превращалось в черную точку). Попытка соединить, при помощи цилиндра, объектив камеры и дверцу, чтобы изолировать свечение ИК-подсветки, не увенчалась успехом. Поэтому для участников была добавлена еще одна подсказка: “find red eyes in black holes”. И теперь участникам, для обнаружения местоположения камеры, нужно было заглянуть в шкафчик через отверстия, и увидеть красный свет от ИК-светодиодов.

First Eye

Флаг также записывается в QR-код, и печатается на специальной конструкции, которая закрепляется на дверце шкафчика:

Cam See

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

Участник получает IP камеры.

Для получения флага участник должен, по изображению с камеры (внутренностям шкафчика), понять где она находится; затем подойти к шкафчикам и перебрать лески; если потянуть за леску у нужного шкафчика, то поднимется QR-код:

Outside

Malevich's? Again?

За неделю до часа X

19 мая о нашем хакспейсе упомянули на habrahabr (Хакатоны и около того), что было приятно видеть, т.к. в разделе PHDays Everywhere нас все еще не было.

Началась подготовка к Old School geo-квесту. Для квеста нам понадобились:

1. старый сканер (для которого отсутствует 64bit драйвер для Win, но который работает под *nix - GNU/Linux, OS X);
2. местоположение (адресацию) 8 случайных книг в библиотеке;
3. 1 книга на английском языке.

Со старым сканером, который мы планировали использовать, возникли проблемы - куда-то пропал его блок питания. На следующий день нашлась ему замена - старый сканер для которого отсутствовал официальный Win 64bit драйвер. Однако у замены был недостаток - официальный драйвер отсутствовал, но можно было установить 64bit драйвер другой модели, и сканер “заведется”, что могло подпортить Old School'ность квеста.

Чуть позже собрали задание с участием git и (не)удаленного коммита. Остаток дня провели создавая задание “Master of hash collisions”.

В “Master of hash collisions” мы хотели познакомить участников с внутренностями созданной системы квестов, в которой ссылка на очередное задание квеста открывается после получения флага на текущее задание квеста. Это, примерно, выглядит так:

URLi+1=AES(message: pre_defined_msg_in_Base64i+1, key: SHA3(flagi))

Изначально мы хотели заменить SHA3 на MD4, и сгенерировать для участников коллизию - 2 флага. Один “псевдо флаг” записывался в комментарий к коду квестовой системы, второй “истинный флаг” - участники должны найти. Также участникам давалось время начала генерации коллизии, и намек на код, генерировавший коллизию.

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

В итоге задание пришлось изменить - не получилось избавится от трех непечатных символов в “флагах”:

‘ХЈњЙЎ¶B'РРыљ‘;пd5‚Jџ__][__Y__г_Лb_џ-__c_a[_________Я_______

‘ХЈњЙЎ¶В'РРkљ‘;пd5‚Jџ__][__Y__г_Лb_џ-__c_a[_________Я_______

В новой версии задания использовался CRC32. В коде также был закомментирован хеш, и появилась проверка на условие “if(flag.len > 9 && flag.len < 14 )”. В коде турнирной таблицы прописалось более точное условие “if(flag.len == 12)”. А новая подсказка намекала на код для обращения CRC32.

Остаток недели прошел менее интересно, и более напряженно. В этом году в последний момент появилось много новых помощников, не знакомых с *trello, и на координацию работы уходило много сил, т.к. единственным способ связи/координации с новичками был телефон. В общем было несколько Scrum-митингов, тестирование связи с Москвой для проведения викторины и телемоста, ..., пока не пришла часть заданий на CTF от Positive Technologies.

К этому моменту мы уже поняли как объединить глобальную историю про USSU (соревнование между площадками) и локальный OmskCTF. Для локального OmskCTF сделали следующую легенду:

Вы – житель омского нано-государства.

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

Ваша задача - раскрыть все тайны вашего государства.

Поэтому в заданиях на локальный CTF от Positive Technologies важно было содержимое флага, чтобы сам флаг раскрывал какой-нибудь секрет о нано-государствах. Либо чтобы была возможность быстро заменить оригинальный флаг задания на свой флаг. Так оно и вышло.

В итоге мы получили 5 заданий категории web (исходники, в основном PHP и Python). В этих заданиях предполагалось, что участник будет взаимодействовать с удаленным сервером. Чтобы не поднимать свой web-сервер, Positive Technologies развернули эти задания на своем сервере, и прислали ссылки. Единственным условием использования сервера PT было - запретить участникам устраивать DoS атаку на него.

А флаги... Флаги были в виде случайной Base64 строки. Благодаря тому, что у нас на руках были исходники всех заданий, то заменить флаг было легко, единственное это потребовало бы поднятия своего web-сервера, его тюнинга, закрытия дыр, не предусмотренных заданием, ... В общем мы всегда любили PaaS, и этот случай не стал исключением. Все PHP и Python скрипты были адаптированы для запуска на Google App Engine.

При адаптации скриптов возникли трудности с одним заданием. Для этого задания требовалось развернуть на сервере Selenium, что уже выходило за рамки PaaS. Было несколько вариантов решения этой проблемы, одним из которых было написание небольшого proxy до сервера PT с уже развернутым Selenium. На этом варианте и остановились.

Затем начался процесс стилизации заданий под единый формат, и генерация квестов.

Немного про Old School квест

Сценариев квеста было несколько. Финальный вариант сценария выглядел так:

• Участник получает подсказку - список книг (8 существующих книг + 1 несуществующая книга - подсказка).
• Начинает искать книги (без помощи библиотекарей, они только могут пояснить адресацию).
• Находит книгу, забирает закладку с 2D Barcode на одной стороне, и подсказкой на другой стороне.
• По содержимому закладки, становится ясно - чтобы прочитать содержимое - надо воспользоваться сканером библиотекарей.
• Открывает сканет - видит, что там уже наклеено 2 бумажки (Dead Zone - вверху и еще один код с текстом - внизу).
• Кладет свою бумажку-закладку посередине.
• Замечает наклеенный на крышку сканера QR-код (с подписью Driver), и устанавливает драйвер.
• Драйвер не ставится - нужна старая Windows.
• Запускает виртуалку, ставит драйвер, прокидывает USB внутрь виртуалки.
• Сканирует.
• По тексту на “нижнем коде” - гуглит, и понимает, что нужно скачать PaperBak.
• Считывает информацию в PaperBak.
• PaperBak декодирует только первый (верхний) блок 2D Barcode с бумажки-закладки, нижний блок (приклеенный листок с еще одним 2D Barcode и с текстом) помечается как не декодированный.
• В графическом редакторе вырезается нижний 2D Barcode, и PaperBak успешно его декодирует.
• Следуя считанным указаниям (нижний 2D Barcode) - просит у библиотекарей “спец-заказ”.
• Книга “спец-заказ” дается на 3 минуты.
• Пользуясь “книжным шифром” (2D Barcode с бумажки-закладки) - начинает расшифровку сообщения.
• За 1 минуту библиотекарь дает подсказку: “Отсканируйте, потом продолжите. И отсканируйте то, что уже просчитали - вдруг ошиблись”.
• В итоге получается строка чем-то похожая на флаг.
• По подсказке в списке книг, и по подсказке считанной PaperBak информации (нижний 2D Barcode) - понимает, что это шифр Цезаря.
• Пользуясь, например, онлайн дешифраторами, определяет, что используется ROT7, и получает флаг.

За день до часа X

Планы на этот день были грандиозные:

1. Небольшая перепланировка библиотеки :)
2. Разворачивание оборудования для трансляции докладов, и вывода турнирной таблицы участников OmskCTF на отдельный TV.
3. Монтаж устройств для geo-квестов.
4. Рассказ библиотекарям про их роль.
5. Проверка сетевых настроек для WiFi (был отдельный VLAN и SSID для трансляции докладов, и отдельный VLAN и SSID для участников CTF).
6. Ожидание звонка от курьера, который должен был привести призы-сувениры.
7. Интеграция с Google Spreadsheet задания “Master of hash collisions”.
8. Подготовка квестов для всех участников (разложить по директориям, подключить систему “сбора достижений”).
9. Возможно было что-то еще...

Можно сказать, что этот день прошел “плавно”. Суета отсутствовала, т.к. 1/3 времени просто были заняты поисками рабочего HDMI кабеля :)

Смонтировать geo-квесты успели только частично (библиотека начала закрываться). Рассказать библиотекарям про их роль не вышло, т.к. сегодня они взяли выходной. Курьер так и не позвонил...

А вот тест WiFi прошел отлично. По сравнению с прошлым годом - все работало.

Этот день закончился где-то в 02:00 - когда мы завершили “распределять” квесты по директориям команд-участников. Это был прогресс - год назад этот же день продлился до 03:00.

К слову о командах, участники одной команды сообщили, что не смогут прийти, а команды от ОмГТУ так и не было (25 мая - студенты погрузились в сессию).

WiFi работает :) (с этой мыслью мы заснули).

Немного про формат проведения CTF

Соревнование состоит из заданий, объединенных в несколько квестов. Квесты выдаются последовательно, один за другим, через каждые 2 часа. Если одна из команд решила (до истечения двух часов) все задания текущего квеста, то она может попросить открыть через 15 минут задания следующего квеста. Задания очередного квеста становятся доступны для всех команд одновременно.

Квесты состоят из заданий следующих категорий: misc, crypto, stego, web, pwn и geo.

Участники, для каждого квеста, получают Google Spreadsheets, который, по ответу на текущее задание квеста, генерирует ссылку на следующее задание квеста (ссылка на первое задание - в примечании к ячейки A2).

Участники должны для каждого из заданий найти “тайну” / “потайное место” (CTF-флаг), имеющий формат “PHD_flag_*”. В случае если ключ верный, команде начисляется 1 балл.

Про то, как мы определяли победителя написано здесь.

Это мало отличалось от того, что было в прошлом году. Основное отличие было в количестве двухчасовых квкстов. В этом году заданий было меньше, из-за этого квестов было всего два. Однако был еще PHD Stock Market.

Общий Timeline выглядел так:

1. старт соревнования – игроки со статусом PHD Stock Market получают первые инструкции от “капитана нано-государства”, остальным участникам команд открывается доступ к первому квесту CTF
2. :)
3. окончание CTF, игроки PHD Stock Market вводят в курс дела остальных участников своей команды
4. конец первого дня – награждение победителей CTF
5. второй день – продолжение PHD Stock Market, и укрепление позиции своего нано-государства
6. ...
7. “Государство, заработавшее больше всего публей, становится победителем, и получает призы от Positive Technologies”

За два часа до часа X

Вспомнив, что в прошлом году в это время мы вспомнили про статью “3 дня без сна или как создать крупнейший киберспортивный турнир за Уралом”, и войдя в рекурсию, у нас включился режим “Фигаро” (вспоминая как кто-то вспомнил как прошел “день до часа X” год назад; кто именно вспомнил, мы уже забыли) :)

“Вспомнив все” нас, на входе в библиотеку уже ждали студенты-помощники - они помогли с монтажом оборудования для geo-квестов. С этого момента мы разделились:

• одни пошли донастраивать оборудование для трансляции докладов,
• другие - подстройкой DSLR под условия освещения,
• третьи - рассказывать библиотекарям про их роль с помещением закладок в книги (для Old School квеста),
• четвертые - разносить список участников охранникам,
• пятые - рассказывали изумленным посетителям библиотеки про PHDays,
• шестые - остались монтировать гаджеты для geo-квестов.

All Ready

в реальности нас было примерно 3 человека - на тот момент мы еще не определились с точным числом

И “секунда в секунду”, как все работы были завершены, пришли первые посетители нашего хакспейса.

Good

OmskCTF — Час X

После небольшой вступительной речи проректора по информатизации и организаторов. В личные директории участников не был загружен первый квест. Участников от ОмГТУ так и не было, и нас попросили начать CTF вместе с началом PHD Stock Market.

Настало время “раздать WiFi”:

Wi-Fi

Через час пришли несколько студентов. Сессия их потрепала, поэтому мы дали им VIP-место - на баблах.

OmSTU Team on Bubbles

Час X (дубль 2)

В личные директории участников наконец был загружен первый квест, что ознаменовало начало CTF! Параллельно началась трансляция докладов.

1/2

Уже второй год первой задачей первого квеста мы делаем вводной - участники знакомились с форматом задач.

7zipJpeg

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

Параллельно со стартом локального CTF включились игроки со статусом PHD Stock Market.

PHD Stock Market Man

Спустя некоторое время команды добрались до первого geo-квеста с камерами.

First Eye Code

В этот момент стало ясно, что с web у участников дела обстоят не очень, и всем командам была дана подсказка.

Stage 1 - In Box

Stage 2 - Try

Stage 3 - Be Happy

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

Thanks To You ;)

Поэтому “первопроходцам”, нужно было все делать быстро, чтобы остальные команды не успели среагировать, и сфотографировать QR-код.

Настало время Old School квеста.

Scanner guarded by librarians

Old Scanner

Old OS

К окончанию первого этапа вперед вырвалась команда “Занято”.

2/2

ADSL vs GPON, or ...

После постижения таинств работы Git'а и сравнения скорости ADSL vs GPON, команда “Занято” добралась до второго квеста с камерами.

I See Black Singularity

Where Is My Red Eyes?

Fortune cookie

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

We Need Two Cookie

За 30 минут до окончания CTF, участники дошли до задания “Master of hash collisions”. В этом задании была одна лазейка: можно было расшифровать ссылку на следующее задание при помощи хеша, спрятанного в коде. Система не засчитала бы текущее задание (на “сервере” были добавлены дополнительные проверки), однако команда смогла бы начать выполнять 2 задания одновременно.

Internet Disconnection

За 10 минут до окончания, кто-то решил еще раз отметить Час Земли, и закрыл выход в Интернет через WiFi. Однако, команды не растерялись и сами подняли AP на своих смартфонах.

Спустя 10 минут, сохранив лидерство, команда “Занято” заняла первое место в PHD OmskCTF 2015.

The Winners is Занято

День второй

В этот день мы уже спокойно наслаждались докладами. Было и несколько сюрпризов, связанных с WiFi - перед самым началом телемоста с Москвой (когда ведущие уже объявили о телемосте) WiFi опять отвалился.

Hacker Quiz и завершение PHDays Everywhere V in Omsk

Под конец для остались несколько человек на Hacker Quiz (большинство из них были студенты, пришедшие, после получения очередного зачета). Участники историю знали плохо, но зато увлекались “социальной инженерией”.

Hacker Quiz

Кто победил? Смотрите в записи.

На этом PHDays Everywhere in Omsk завершил свою работу.

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

Несколько ссылок: пресс-релиз мероприятия, событие в G+, VK, Фотки (если их смотреть в режиме слайд-шоу и читать подписи, то получится небольшая история; не забывайте нажимать на зум/лупу на верхней панели - фото загрузится в оригинальном качестве), Видео (пока не все выложено/обработано).

Мы уже третий год организовываем PHDays Everywhere в Омске, и в отличие от предыдущих лет решили устроить “нулевой день” - OmskCTF.

Подготовка

За неделю до часа X

Начинаем разгребать список задач из Trello.

Как выглядит Trello сейчас.

Первым делом необходимо было достать IP-Камеры, их мы планировали использовать в паре заданий CTF. И так удачно сложились обстоятельства, что нам одолжили несколько резервных камер, используемых в университете, фирмы ***.

В этих заданиях предполагалось, что участникам предстоит взломать камеры для получения изображения с них (логин/пасс участником не был известен). Благо большинство оригинальных прошивок IP-Камер уязвимы (-1-, -2-, -3-, -4-), и прошивки полученных камер не стали исключением. Все полученные камеры были одной модели, поэтому мы решили, что достаточно найти уязвимости только у одной из них (как выяснилось позже, зря мы так думали). Поиск уязвимостей продлился недолго, спустя ~30 минут у нас в арсенале уже было несколько уязвимостей (спасибо китайцам за комментарии к коду - они не понадобились), которые помогут участникам соревнования получить картинку с камеры не имея логин/пасс. На самом деле, даже была обнаружена уязвимость, превращающая камеру в высокотехнологичный кирпич, и мы стали опасаться, что кто-нибудь из участников ей воспользуется.

Уже близился момент развешивания камер по местам, и мы взялись за настройку/проверку остальных камер. Наше удивление не имело границ, когда эксплойт заработал только на части оставшихся камер. Часть камер (напомню, что модель одна и та же) не была уязвима. Через некоторое время мы заметили, что web-интерфейс “неуязвимых” камер более глючный, и в нем отсутствуют некоторые функции, которые есть в уязвимых камерах. И в этот момент мы решили проверить версию прошивки “неуязвимых”. Наши догадки подтвердились, “неуязвимые” имели старую прошивку, а уязвимые - последнюю. Это было странно, и мы погрузились в Интернет, в поисках информации о этих прошивках. В итоге выяснилось, что уязвимости в последней прошивке давно известны, и производитель о них уведомлен, но закрывать их не спешит.

Интересно то, что уязвимости касаются именно новых функций, появившихся в последней прошивке. Это напоминает картину:

Мы решили не обновлять прошивку до финальной (банально не хватало времени, и кнопка “выбрать файл прошивки для обновления” не работала ни в одном из используемых браузерах), а для участников придумали другой способ получения логин/пасс.

Остаток недели прошел менее интересно, в переговорах, планировании, тестировании связи с Москвой для проведения викторины и телемоста, ..., пока не пришла часть заданий на CTF от Positive Technologies. Мы, так же как и в прошлом году, ожидали получить список заданий и ответы на них. В прошлом году, для автоматического зачитывания баллов за флаги, мы использовали простую схему, основанную на Google Формах и Таблицах. В этом году мы хотели применить нашу квестовую систему, в которой ссылка на очередное задание квеста зашифрована ключом, ключ - это найденный флаг от предыдущего задания квеста. Именно поэтому нам важно было получить как сами задания, так и ответы на них (для самостоятельного поиска ответов поджимало время). В этом году пришли только задания + ссылка на сайт для проверки флагов... Это несколько выбило нас из графика, однако просьба выслать нам ответы (флаги) была поддержана организаторами PHDays, и мы получили флаги некоторое время спустя.

Затем начался процесс стилизации заданий под единый формат, и генерация квестов.

Немного про задания с камерами

Изначально задания были простыми:

• Флаг записывается в QR-код, и вешается на стенку в коридоре, на него направляется IP-Камера.
• Участники получают координаты конкретного места + диапазон IP-адресов, в котором находятся камеры.
• Участник может получить флаг двумя способами: прогуляться до места, либо найти нужную IP-Камеру.
• Доступ к камерам можно получить только из одного места (подключившись к конкретной WiFi точке доступа).

Спустя некоторое время задания трансформировались:

• Теперь участник получает IP конкретной камеры, и список мест, где могут находится камеры.
• QR-коды размещаются в каждом таком месте, но теперь QR-код не попадает в поле зрения камеры.
• Задание представляет собой монолит (все задания с камерами объединились в одно), а в QR-кодах записан IP следующей камеры.
• Участники теперь должны работать в команде:
  1. один участник сидит, и наблюдает за камерой;
  2. другие проходят по местам и “машут в камеру”, пока их не заметит первый участник команды, затем они считывают нужный QR-код.

Однако, в “трансформированном” варианте можно получить флаг, даже не взламывая камеры - достаточно пройтись по указанным местам и перепробовать все флаги.

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

• Использовались только 2 камеры.
• Участник получает IP первой камеры.
• После получения доступа к изображению с камеры, он также получает список мест (overlay текст на изображении с камеры).
• Далее начинается командная работа “в поисках QR”, аналогичная “трансформированному” варианту.
• Теперь во всех QR-кодах записаны валидные (начинающиеся с ключевого слова) флаги.
• Первое задание завершается по нахождению QR-кода рядом с заданной камерой.
• Во втором задании надо также получить доступ к камере, однако теперь overlay содержит не список мест, а Diff (2D графический xor двух QR-кодов).
• Участники, используя список мест, полученный на первом задании, также должны найти нужный QR-код, и, используя Diff, восстановить исходный QR-код, в котором и будет флаг.

За день до часа X

Вкратце можно описать как: “Фигаро тут, Фигаро там”:

1. Именно на этот день была назначена встреча с администраторами по завершению конфигурировании сети для проведения CTF: отдельный vlan, несколько SSID на точке доступа с разными приоритетами (для организаторов > для участников > для всех остальных).
2. Также в этот день пришли призы-сувениры (блокноты и ручки) от Positive Technologies.
3. В этот день нужно было настроить систему (установить Flash-плагин к браузеру) для трансляции докладов с PHDays.
4. Встретить студентов, которые согласились за 2 дня подготовить (прибраться и сделать небольшую перепланировку) 2 аудитории к трансляции PHDays.
5. Передать списки участников охранникам.
6. Подготовить квесты для всех участников (разложить по директориям, подключить систему “сбора достижений”).
7. Проверить QR-Коды (наши коменданты любят их отклеивать).
8. Чат-совещание организаторов в 22:00.
9. И еще что-то.

Стоит сказать, что мало что из этого списка прошло гладко (лучше всего прошло получение призов-сувениров от курьера).

В остальном, администраторам пришлось переконфигурировать сеть для поддержки 70 устройств (8 команд x 4 человека x 2 устройства + 6 дополнительных устройств), это не прошло гладко (были проблемы с ACL, маршрутами, IPv6, ...). Из-за этого сменились IP у камер, и пришлось перегенерировать связанный с ними квест, что не прошло бесследно (к чему это привело описано ниже). Про несколько SSID и приоритеты пришлось забыть. У студентов возникли “срочные дела”. К началу дня не все из участников успели зарегистрироваться, поэтому список охранникам пришлось отправлять в 23:00, и только с этого момента начать “распределять” квесты (процесс распределения продлился до 3:00).

К счастью все QR-коды остались на месте.

Немного про формат проведения CTF

Соревнование состоит из заданий, объединенных в несколько квестов. Квесты выдаются последовательно, один за другим, через каждые 2 часа. Если одна из команд решила (до истечения двух часов) все задания текущего квеста, то она может попросить открыть через 15 минут задания следующего квеста. Задания очередного квеста становятся доступны для всех команд одновременно.

Квесты состоят из заданий следующих категорий: misc, crypto, stego, web и geo (IP-Камеры).

Участники, для каждого квеста, получают Google Spreadsheets, который, по ответу на текущее задание квеста, генерирует ссылку на следующее задание квеста (ссылка на первое задание - в примечании к ячейки A2).

Участники должны для каждого из заданий найти ключ (флаг), имеющий формат “PHD_flag_*”. В случае если ключ верный, команде начисляется 1 балл.

Про то, как мы определяли победителя написано здесь.

За час до часа X

Вспоминая статью “3 дня без сна или как создать крупнейший киберспортивный турнир за Уралом”. Так, как нам выделили помещение-коридор, рядом с которым всё это время шел ремонт, то всё “оснащение” помещения пришлось производить в самый последний момент.

К нашему приходу помещение уже прибрали (спасибо уборщице, в прошлый день цементная пыль была буквально везде, а сейчас все чисто). И мы с несколькими студентами-участниками начали переставлять столы, заносить оборудование, и заносить стулья. Со стульями возникла проблема - они, внезапно, все оказались в цементной пыли, и пришлось быстро их чистить.

Далее была быстрая проверка работы WiFi, IP-Камер, Интернета. Всё работает, но это продлилось недолго. Через некоторое время пытаемся подключить оставшиеся ноутбуки к WiFi - не подключаются. Пытаемся подключиться со смартфонов - аналогичная картина. Однако все устройства спокойно подключаются к публичному SSID. Ok (думаем мы), Интернет у нас есть, но для доступа к IP-Камерам нужно подключение к ново-созданному SSID. В этот момент приходит администратор, и... Ну, в общем, ничего кардинально не изменилось. Мы сменили пароль на более простой, разблокировали TKIP, и смартфоны смогли подключится, однако доступа к сети не было...

WiFi pass

В итоге, решили пока говорить всем, чтобы подключались к публичному SSID.

OmskCTF - Час X

После небольшой вступительной речи декана нашего факультета, и проректора по информатизации, в личные директории участников был загружен первый квест, что ознаменовало начало CTF!

1/3

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

7zipJpeg

Изначально планировалось тем командам, которые в течение первых 30 минут не распознают формат, дать подсказку. Спустя 30 минут некоторые команды воспользовались этой подсказкой.

В течение первых двух часов были даны еще несколько подсказок (подсказки получали одновременно все команды). За 15 минут до окончания первого этапа, команда “CAT_IN_THE_DARK_WOOD” взяла все флаги первого квеста, и устроила себе кофе-брейк.

2/3

Первые задачи второго квеста требовали подключения к IP-Камерам, и, следовательно, подключения к другому SSID. Нам повезло, во всех командах нашелся хотя бы 1 человек, оборудование которого смогло успешно подключится к необходимому SSID. Однако и здесь без происшествий не обошлось, crazy-DHCP сервер стал раздавать разным клиентам один и тот же IP!

IP-Camera

Спустя некоторое время выяснилось, что при множественной эксплуатации уязвимости IP-Камер, браузеры клиентов просто зависают. Это пришлось быстро исправлять при помощи нескольких костылей (они настолько ужасные, что описывать их не хочется).

Quiet!

Go-Go-Go!

Спустя еще некоторое время случилось то, о чем упоминалось в “За день до часа X” - перегенерация не прошла бесследно - флаг на первое задание был случайно изменен на “чистый” флаг от второго задания. Тем не менее, для участников, этот “баг” лишь упростил задание - теперь флаг располагался в ближайшем “возможном месте” от места проведения CTF. И большинство команд, увидев, что первый флаг “подходит”, не стали “махать в камеру”.

Snapshot

Snapshot of paradise

Cicada QR-Code

Часто, в подобных соревнованиях, эти “баги” делают процесс решения задачи только интереснее. Главное, чтобы от этих “багов” задачи не становились невыполнимыми.

Первой командой, которая получила второй флаг второго квеста, была “hackup”. Через некоторое время к ним присоединились “rm -rf”.

Как можно было решить второе задание с камерами

Самый быстрый способ - это взять библиотеку для считывания QR-кода, и добавить в Diff опорные точки (position, alignment, and timing patterns):

Структура QR-Кода

Далее необходимо немного подправить библиотеку: открываем одновременно 2 изображения (снимок QR-кода и измененный Diff), ..., при чтении данных - читаем их одновременно с двух изображений и делаем xor, ... На выходе получаем искомый флаг.

Второй способ - распознать QR-код, и сгенерировать его заново с сохранением исходной версии и формата QR-кода. Затем, в графическом редакторе указанным способом обработать эти изображения. И после чтения полученного QR-кода, получаем искомый флаг.

Diff

Самый медленный способ - используем графический редактор для совмещения кодов. После обработки “указанным способом”, убираем образовавшиеся “границы”:

Try to merge

Затем считываем код, и получаем искомый флаг.

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

Некоторые решили сделать все “вручную”:

Binarization

Прошли 2 часа второго квеста. В этот раз ни одна из команд не достала все флаги за 2 часа. 

3/3

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

Третий этап длится 3 часа (которые были увеличены на 5 минут, т.к. первый этап длился на 5 мин. меньше из-за вводной части).

В общем, эти 3 часа прошли спокойно. Самое интересное началось за 10 минут до окончания соревнования.

Вначале этих 10 минут в лидеры вырвалась команда “rm -rf”, и буквально за минуту до окончания соревнования первенство перешло к команде “brizz” (участники которой, решили сохранить анонимность).

The Winners is brizz

CTF этого года получился разнообразным, и практически каждая команда была какое-то время в лидерах за эти 7 часов. Все остались довольны:

All world in our hands

Финальная турнирная таблица (вкладка Snapshot).

PHDays 4 - Час Y

За 2 часа до часа Y

Так как в “За день до часа X” встреча со студентами, которые согласились помочь с уборкой помещений, не состоялась, то в этот день решили прийти пораньше. Когда пришли, мы увидели то, что ожидали увидеть: никто без нас не прибрался в помещениях. Поэтому первый час прошел примерно так: тряпку в руки, швабру в ноги, и мыть.

Welcome to PHDays

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

За 15 минут до часа Y

Уже стали приходить первые гости, и настала пора подключится к трансляции PHDays \V.

The door opens

Здесь нас ждал очередной сюрприз.

Для трансляции PHDays нужен только браузер+Flash. Изначально в системе, подключенной к проектору отсутствует Flash-плагин (система используется как аналог AIRTAME), поэтому в “За день до часа X” этот плагин был установлен.

Однако, только что открывшаяся страница трансляции, встретила нас предложением установить Flash-плагин. Это могло означать, что в определенный момент, после установки Flash-плагина, пропало питание.

Все дело в том, что эта система “заморожена”, и после перезагрузки/выключения возвращается в исходное состояние.

Через 5 минут плагин был установлен, и мы опять попытались открыть страницу трансляции.

Браузер - IE10

Теперь нас ждал очередной сюрприз, но уже от фильтра SmartScreen, который заблокировал Flash-плеер на странице. Спустя некоторое время “понижения безопасности браузера” Flash-плеер успешно загрузился, и началась трансляция с залов.

Mmmmm...

В одном из помещений началась трансляция зала “Конференц-зал”, а в другом - “Зала-трансформер”.

Спустя несколько минут просмотра в HD разрешении, мы поняли, что Intel Atom D525 “не тянет” такой поток (его ядро было полностью загружено), и переключили на SD. Странно, то, что год назад декодирование видео ускорялось на NVIDIA ION 2 GT218, а в этом году - нет. Новый Flash-плеер, или Flash-плагин перестали поддерживать ускорение? Вероятно это так.

По окончании доклада “Специализированные решения — панацея? Поговорим о MDM, BYOD и проч.” мы показали, как выглядит MDM (Mobile Device Management), встроенный в Google Apps, для его администратора. Затем переключились на зал “Пресс-центр”.

С этого момента начался HackQuest. К сожалению, большинство участников OmskCTF (включая победителей) решило участвовать в нем “из дома”, что по нашему мнению было ошибкой - мы не смогли им помочь.

Затем мы переключились на доклад “Отдай мне свои данные!” (мы думаем, что это один из тех докладов, которые интереснее смотреть в переводе - диктор был отличным!). К сожалению (или к счастью) при просмотре трансляции было несколько разрывов связи.

В момент разрыва Дейв показывал снимки кредитных карт, которые пользователи выложили в сеть. Мы решили самостоятельно продолжить его рассказ, и рассказали о произошедших случаях, с наши знакомыми. Случаи были похожими: в смартфоне (Android, iOS) хранились фото кредиток, и в определенный момент их пользователи решили подключить на них свой Google аккаунт. При этом включилась автозагрузка фото в Google+. На этом моменте все нормально - загруженные фото остаются приватными (их не видят остальные пользователи G+), однако через некоторое время наш пользователь заходит в свой G+ профиль, и, увидев там новые фото, решает написать другу “зацени мои фото”. Тот естественно ничего не видит, т.к. прав нет, и наш пользователь, пытаясь все-таки показать свои шедевры другу, открывает всем пользователям G+ доступ ко всему альбому автозагрузки. Вы же помните, что там были фото кредитки? А вот наш пользователь, похоже, об этом забыл... Причем в G+ существует такая особенность, что если сохранить ссылку на пред-просмотр фотографии, то даже если автор уберет права на её просмотр, эту фотографию можно будет открыть по сохраненной ссылке.

В ходе своего доклада Дейв также показывал проданные б/у HDD с ценной информацией. К сожалению больше разрывов связи не было, и по окончании его доклада мы принесли “посыпавшийся” HDD (Seagate Barracuda ES.2, который, при наличии мухи CC, проработал 5 лет) умершего сервера. И показали, что с такого HDD информацию удалить сложно (при чтении/записи первого Bad-блока HDD блокируется) не имея электро-магнитного уничтожителя данных, либо не имея шредера.

Также некоторые из наших посетителей небыли знакомы с устройством современных SSD, и мы рассказали, что, при наличии включенного TRIM и автоматического сборщика мусора, восстановить удаленные файлы - невозможно.

Hacker vs Laptop

Чуть позже на нашей площадке начался конкурс “hacker vs laptop”.

Who can try to hack?

Участникам давался ноутбук, задача участника - оставить след в системе в виде программы, запускающийся при загрузке системы, либо в виде программы, запускающийся при открытии папки/диска. Проверка успешного выполнения задания осуществлялась перезагрузкой системы. Правил было несколько: не разбирать ноутбук, и проводить любые действия только после полной загрузки системы.

Our toys

В конкурсе были и призы, 3 первых человека, которые справятся с задачей - получат ручку от Positive Technologies. А, если никто не справится, то ручки получат “самые упорные”.

Hack!

Конкурс проходил все 2 дня.

Hacker Quiz

Через некоторое время началась викторина между площадками. Мы соревновались с Москвой и с площадкой из Индии. Здесь комментарии будет мало, т.к. викторина доступна на записи. Единственное, что хотелось бы отметить: жаль, что мы не записали весь процесс с нашей стороны (веб-камера и направленный микрофон всего не покажут).

День второй

Ко второму дню мы подготовили небольшой сюрприз. Это был мастер-класс о том, как даже небольшие ошибки дизайна (имеется в виду логика работы, а не графический интерфейс), при определенном стечении обстоятельств, могут нивелировать все принятые меры защиты информации. А т.к. в этот день должны были выступать представители Mail.RU, то мы решили посветить свой мастер-класс продуктам Mail.RU. И показали, что классические методы защиты пользователей-паранойков (настройка браузера на автоматическую очистку Cookie при выходе, либо использование режима “инкогнито”) могут не только защитить реквизиты пользователя, но и наоборот - стать причиной их утечки.

После мастер-класса оставалось еще много времени до выступления Mail.RU, поэтому вернулись к основной программе трансляций PHDays.

Телемост с Москвой

Уже третий год телемост проводится с использованием Cisco WebEx.

WebEx - это такая “штука”, для работы которой нужен дырявый плагин Java.

Обычно мы устанавливаем Java и клиент WebEx только на время проведения мероприятия, после этого они удаляются из системы. С WebEx связана еще одна проблема: на планшетных ПК (ASUS Eee Slate EP121, Samsung Series 7 Slate, Microsoft Surface Pro, Samsung ATIV Q, ...) под Win8, в которых основными манипуляторами выступает touch-экран и Wacom-перо, невозможно нажать на кнопки в модальных окнах WebEx’а. Поэтому приходится подключать классическую мышку.

Однако в этом году нас ждал еще один сюрприз. Как было написано в “За неделю до часа X”, мы протестировали связь, и она, как и в предыдущие годы, была хорошей. В этом году, после подключения к телемосту, мы поняли, что не все пройдет гладко - голос ведущих был очень плохого качества (внезапные паузы, высокая степень сжатия потока).

<_<

Однако в Москве нас было слышно нормально (запись телемоста). Из-за такой связи нам было трудно понять когда закончится перевод на английский, и иногда возникали наложения... К тому же некоторые из присутствующих были у нас первый год, и забыв про перевод на английский, выступали с “речью”. Впрочем, смотрите запись 8-O

Hacker vs Laptop

В этот день конкурс продолжился. За весь прошлый день ни одному из участников не удалось скомпрометировать систему. В этот день активность участников многократно возросла, было применено множество способов “оставить свой след в системе”, но система осталась неприступной. В итоге самые “упорные” участники получили сувениры. Этими участниками стали “ghostilya” и “Shizoid”.

Последний доклад

Последней трансляцией на нашей площадке стал доклад “Импрессия: не ломай — сделай свой ключ”, в ходе которого было рассказано еще несколько “историй” :)

На этом PHDays Everywhere in Omsk завершил свою работу. Всем легкого пентеста! И до новых встреч в следующем году на PHDays V.

В первый день эксперты в своей области рассказывали о  Google Admob, Google Maps, Android, AngularJS, Google Glass. В перерывах можно было поучаствовать в тестировании приложения "Терапевт", созданного ребятами в GDG-labs, посмотреть Chromebook и Google Glass, сыграть в настольные игры. Закончилось все Ignite (это супер-формат!). Это несколько выступлений за небольшой промежуток времени (одно выступление 5-10 минут).

Во второй день проходили мастер-классы по разработке приложений на Android и расширений Google Chrome, сама конференция прошла в формате Barcamp. В каждой из трех аудиторий обсуждали только самые интересные темы, так как темы дискуссий выбрали сами участники и докладчиками были сами участники. Одна из аудиторий была полностью посвящена разработке под Android, в другой представляли свои проекты и рассказывали о набирающей популярность игре от Google Ingress, в третьей обсуждали разные технологии. Закончилось все обсуждением предстоящей конференции в Омске HappyDev и проблемой отсутствия девушек-программистов.

В самом конце состоялся круглый стол, где обсуждали возможности IT-сообщества в Омске.

Судя по отзывам, конференция прошла на ура.

Ребята, сейчас в Омске создалась невероятная IT-атмосфера, позволяющая творить и создавать. Приходите, пробуйте себя и не бойтесь посещать такие мероприятия! Календарь Omsk It-events.

Спасибо всем, кто был! Приносите новые вкусняшки (и реальные к чаю, и виртуальные для мозгов :) Заседания клуба в этом семестре – каждый вторник, 10:00-11:35, ауд. 8-210.

1. Смотрели и обсуждали фотки с очередного DevFest'а, который провели Google Development Group Omsk 2-3 ноября в ОмГУ. Это что-то вроде съезда айтишников, интересующихся технологиями Гугла, с приглашением зарубежных гостей в обучающих целях.
2. Обсуждали планы НИЛ ИМСАИТ (кто не знает, это научно-исследовательская лаборатория «Имитационное моделирование, системный анализ и информационные технологии», которая находится на нашей кафедре, в 8-208, и объединяет сотрудников, аспирантов, магистрантов и студентов кафедры, работающих над её проектами). Рассуждали о том, как в Омске внедрить интеллектуальную информационную систему управления светофорами, подобную тем, которые уже существуют в некоторых мировых мегаполисах, например, в Нью-Йорке.
3. Воочию наблюдали чудо – маленькую платку (см. фото), называемую Raspberry Pi (поэтому-то вы видите на логотипе малинку), которую Евгений Ринатович подключил к проектору и USB-хабу, подцепил клавиатуру и мышь, воткнул SD-карту и… запустил на ней Линукс! Кто не слышал о таком, читайте тут. Возник только один вопрос: а зачем Евгению Ринатовичу такая игрушка за 2350 рублей (плюс USB-хаб за 750 руб. и SD-карта за 420 руб.; информация со свежей накладной из DNS)? Дело, как оказалось, вот в чём. Нам на кафедре в скором будущем придётся подключить USB-ключ, обеспечивающий лицензию для MaxPatrol от Positive Technologies. Работать это ПО будет на виртуальном сервере (Xen). Чтобы заставить виртуалку видеть физическую флешку, существует приспособа USBoverEthernet, делающая из флешки, по сути, IP-флешку, и стоит эта штука около 16000 рублей, если вообще повезёт её достать. Кафедра АСОИУ решила вопрос за 3,5 тыщи %)

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

Приложение Music Paint  разработано на графическом «движке» Unity, который для ребят оказался новым, и большая часть времени хакатона ушла на его освоение. Программисты работали удаленно, только Александр Кузнецов, который готовил серверную часть, присутствовал на хакатоне очно. Видеодемонстрация работы приложения на компьютере Дениса Визигина, программировавшего для Windows, была снята на телефон, но и она была сорвана из-за проблем с интернетом. Но несмотря на все трудности, жюри дало наивысшую оценку новому приложению, и ребята заняли первое место. Основная цель была выполнена — идея, которая вынашивалась около месяца, проверена, а готовое приложение будет выпущено в 2014 году.

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

По материалам онлайн-журнала «Класс»

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

1. Мир пытается оставить тебя тупым. Начиная от банковских платежей и процентов и заканчивая чудо-диетами — из необразованных людей легче вытрясти деньги и ими проще управлять. Занимайтесь самообразованием столько, сколько можете — для того, чтобы быть богатым, независимым и счастливым.

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

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

4. Старайтесь постоянно общаться со всеми. Станьте мастером общения. Учитесь находить в человеке то, что вам нравится в нём, а затем обращайтесь к этой его стороне.

5. Не теряйте времени на скромность. Скромность — это вера в то, что ваши эмоции могут стать судьями вашего процесса принятия решения, в то время как верно прямо противоположное.

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

7. Старайтесь максимально часто общаться с людьми, которые старше вас. Ценность общения со старшими заключается в том, что система принятия решений ваших сверстников не сильно вам поможет. А старшие к тому же знают всё то, что вы узнаете позже — потому стоит спросить у них.

8. Ищите людей круче себя [в том, что вам интересно] и проводите время с ними. Это само по себе важно, но важно и следствие — не пытайтесь быть средненьким в вашей группе, пытайтесь стать лучшим (делайте интересные вещи, будьте честолюбивы, отзывчивы, восприимчивы).

9. Со временем вы будете становиться всё более консервативными. Это просто факт. Те, кто окружает вас, создадут нечто вроде пузыря, который будет поддерживать «статус кво» (текущее положение дел). Именно поэтому самые сумасшедшие идеи нужно реализовать СЕЙЧАС. Потом вы станете слишком боязливы. Поверьте мне.

10. Максимально сократите расходы. Это позволит вам создать запас для осуществления той самой сумасшедшей идеи, о которой я говорил выше.

11. Вместо получения статуса с помощью объектов (что даёт только временное его повышение), повышайте его опытом. Другими словами, поездка в Париж — лучший выбор, нежели новый шкаф. Исследования показывают, что такой выбор повышает уровень удовлетворения, получаемого от жизни.

12. Если вы живёте в нужде, решите денежную проблему. Используйте интернет, поскольку он может помочь вам дёшево купить что-то на аукционах. Если сейчас вы живёте от зарплаты до зарплаты, расширьте это период на три недели вместо двух. Затем, когда дела пойдут лучше, можно планировать на месяц, потом на три, шесть и наконец на год вперёд. Цель — достичь момента, когда вы планируете на 5 лет вперёд.

13. Научитесь проектировать. Это отлично развивает логику, память и воображение.

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

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

16. Хорошо высыпайтесь. Сон и самостоятельное приготовление пищи помогут вам не набрать лишний вес. Если вы думаете «я отосплюсь в могиле» или «я должен ещё много сделать, нет времени для сна», то я вам скажу так — «не выспавшийся вы НЕ ЭФФЕКТИВНЫ», сокращение времени сна вам не поможет.

17. Заведите себе приложение-записную книжку. Не доверяйте памяти, встроенной в ваш мозг. Не доводите ситуацию до делания того, что «вам кажется» нужно было бы сделать. Доверяйте только записям.

18. Поставьте себе большую цель и позвольте случаю помочь вам. Если же вы не обозначите её, то что-то, конечно, случится, однако если вы её поставите, то случится намного больше.

19. Станьте специалистом в чём-то одном. Потратьте 5 лет на дело, а не на шатание вокруг да около. Если вы захотите затем сменить профессию — вперёд. Но выберите что-то.

20. Не пытайтесь исправить людей. Лучше найдите тех, кто ещё не испорчен.

Источник: http://www.adme.ru

Продолжение темы про заморозку системы.

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

Мало кто знает, что помимо версий Windows для простых смертных (Home, Professional, Ultimate, ...), корпоративных  версии (Enterprise), и серверных версий (Windows Server), существуют несколько версий Windows для встраиваемых систем (Embedded). Именно в Windows Embedded присутствует специальный модуль (EWF), который позволяет "заморозить" систему.

Далее описывается история установки и настройки Windows Embedded Standard 7 с EpicFAIL'оми и счастливым концом.

Недавно пришлось создать одну встроенную систему на базе неттоп'а (Intel Atom, NVIDIA Ion, 2 GB DDR3, SSD 64 GB). Изначально планировалось установить на него GNU/Linux из-за лучшей возможности кастомизации, и возможности "заморозки" системы при использовании специальных файловых систем (Aufs, UnionFS). Однако, как всегда, возникли сложности на пути завоевания Linux'ом кремневых сердец. Встраиваемая система состояла не только из неттоп'а, но и из других устройств, разработчики которых написали ПО только для Windows, и, стоит признать, это ПО было написано хорошо. И так, в очередной раз, победила Винда  T_T  .

Благо, что существует Windows Embedded Standard, который позволяет устанавливать только те компоненты системы, которые будут нужны, что важно при использовании SSD малого объема (установленный Windows Embedded Standard 7 занял 3-4GiB, тогда как обычный Windows 7 занимает 8-10 GiB), и содержит EWF (в статье описывается, как перенести модуль EWF из Windows Embedded в обычную Windows):

Расширенный фильтр записи (Enhanced Write Filter, EWF) — это дополнительный компонент, использующийся в Windows Embedded. EWF делает дисковый том доступным только для чтения. При этом операции записи, которые выполняются с данными, хранящимися на этом дисковом томе, перенаправляются в его наложение, которое может находиться на другом диске или в памяти компьютера. Windows рассматривает наложение EWF и его дисковый том как единое устройство. При этом фактически на дисковом томе не происходит изменений. Все изменения сохраняются только в наложении EWF. Изменения можно сохранить на дисковый том в любой момент времени.

Первый EpicFAIL: спустя несколько дней после установки Windows Embedded Standard 7, вышла финальная версия Embedded Standard 8.

Процесс включения EWF

Во-первых, для работы всех возможностей EWF нужен специальный загрузчик (он выбирается на этапе установки системы).
Во-вторых, желательно перенести pagefile.sys на другой раздел. И создать отдельный раздел для логов, документов, и остальных часто изменяемых файлов, которые не требуется замораживать. Также надо выполнить еще несколько подготовительных действий перед активацией EWF, однако в этой статье они описываться не будут, ибо, как раз в этот момент и произошел EpicFAIL...

Main EpicFAIL

Несколько фактов:

• Вся информация о тонкой настройке EWF была взята из MSDN для Windows Embedded Standard 2009, т.к. без глобального поиска по всему MSDN, раздел про EWF в Windows Embedded Standard 7 не был найден (однако сам модуль EWF присутствует в Windows Embedded Standard 7).
• Как написано в цитате выше, EWF может размещать наложение либо на диске (Disk Mode), либо в RAM. Планировалось использовать Disk Mode, т.к. хоть оперативки и 2 GiB, её все равно мало для планируемого сценария использования.

При попытке включить EWF Disk Mode выяснилось следующее:

Windows Embedded Standard 7 only supports EWF RAM and RAM Reg modes. Disk mode is not supported.

>:) >:)

Эта строчка приводится в документе: Enhanced Write Filter with HORM (Windows Embedded Standard 7 Service Pack 1). И если описание EWF для Windows Embedded Standard 2009 находится по пути: 

Windows Embedded Standard 2009
 |- Developer Reference 
  |- Design a Run-Time Image 
   |- Enhanced Write Filter

, то для Windows Embedded Standard 7 этот путь выглядит иначе: 

Windows Embedded Standard 7 
 |- Windows Embedded Standard 7 Technical Reference 
  |- Embedded Enabling Features Technical Reference 
   |- Enhanced Write Filter with HORM

Спасение

Спустя некоторое время блуждания по просторам сети в поисках ответа на вопрос: «На что MS заменила EWF Disk Mode? Не могли же они просто выкинуть эту фитчу. Или же могли!?», была найдена замечательная статья: "Disk Mode Write Filter or Resetting Differential VHDs" (bat'ники приведенные в той статье отличаются от bat'ников, приведенных в этой статье).
В статье-спасителе предлагается использовать dVHD вместо EWF Disk Mode.

Начиная с Windows 7, загрузчик ядра системы поддерживает загрузку из VHD файлов (Native VHD boot).

Virtual Hard Disk (VHD) — формат файла, содержащий полную структуру и содержание сходные с жёстким диском. Используется для хранения виртуальных операционных систем, программ и других файлов в одном файле-образе, который можно открыть разными программами виртуализации или виртуальными машинами.

EWF -> dVHD

Инструкция:

1. Делаем бекап системы.
2. Необходимо очистить систему от EWF:
   1. отключаем FBWF driver

      HKLM\SYSTEM\CurrentControlSet\services\fbwf
      "start" = dword:00000004

   2. читаем раздел «Установка EWF на Windows 7» статьи Внедрение Enhanced Write Filter (EWF), и делаем всё наоборот.
3. Мы будем использовать dynamically expanding VHD, у которых есть одна особенность - при загрузке с них (Native VHD boot), они "разбухают в размере". Чтобы предотвратить "разбухание", необходимо внести изменения в реестр (Step 12: Prevent the VHD from expanding to its full size; на русском: Ограничение увеличения динамических VHD при загрузке):

   HKLM\SYSTEM\CurrentControlSet\services\
    FsDepends\Parameters 
   "VirtualDiskExpandOnMount"=dword:00000004

4. Создайте временный (дополнительный) раздел на SSD для временного хранения VHD, либо подключите внешнее хранилище (SSD или HDD). Далее предполагается, что VHD располагается по адресу: 

   Z:\VHD\PROJECTOR_PC.VHD

5. Перенесите системный (С:\) раздел на VHD (самым быстрым способом является использование утилиты disk2vhd; я настоятельно рекомендую перезагрузить ПК перед запуском disk2vhd). Перед этим этапом лучше удалить весь мусор с системного раздела, и оптимизировать загрузку системы (compact не используйте!).
6. Сгенерируйте новую подпись диска и запишите ее в MBR VHD. Это произойдет автоматически при монтировании VHD.
7. После монтирования VHD желательно удалить из него первый (100 MiB) раздел (в оснастке "Управление дисками" команда "Удалить том...").
8. Освободите букву системного диска (C:).
   

   В Windows системному разделу назначается буква диска (C:). Это соответствие (раздел - буква диска) сохраняется в реестре. Если не освободить (удалить запись в реестре) букву диска (C:), то при загрузке с VHD новому системному разделу (на VHD) будет присвоена новая буква. Смена буквы диска не повлияла бы на работу программ, если бы у всех программистов руки росли из нужного места, но мы живем не в идеальном мире, и часть программ продолжает обращаться к старому системному диску (C:).

    Чтобы этого избежать нужно освободить букву диска (C:):

   1. загрузите куст реестра с VHD:
      1. откройте редактор реестра (regedit);
      2. выберите раздел 'HKEY_LOCAL_MACHINE';
      3. в меню 'Файл' выберите команду 'Загрузить куст';
      4. откройте файл '<точка монтирования VHD>:\Windows\System32\SYSTEM';
      5. в поле 'Имя раздела' введите '_temp';
   2. удалите букву системного диска:
      1. откройте 'HKEY_LOCAL_MACHINE\_temp\MountedDevices';
      2. удалите или переименуйте '\DosDevices\C:';
   3. выгрузите куст:
      1. выберите раздел 'HKEY_LOCAL_MACHINE\_temp';
      2. в меню 'Файл' выберите команду 'Выгрузить куст'.
9. Демонтируем VHD, и пробуем загрузится с него:
   1. создайте запись в BCD (действия происходят в консоли администратора) (составлено на основе статей: 1 2 3 ):
      1. создаем новую запись на основе существующей записи:

         bcdedit /copy {current} /d "Windows VHD"

         BCDEdit вернет GUID вновь созданной записи;

      2. указываем путь к VHD для загрузки (замените GUID на GUID из предыдущего этапа):

         bcdedit /set {GUID} device ^
         vhd=[Z:]\VHD\PROJECTOR_PC.VHD

         bcdedit /set {GUID} osdevice ^
         vhd=[Z:]\VHD\PROJECTOR_PC.VHD

      3. дополнительно, для некоторых систем, необходимо включить detecthal (не забудете заменить GUID):

         bcdedit /set {GUID} detecthal on

   2. перезагрузите систему, и, при загрузке, выберите "Windows VHD";
   3. если загрузка прошла успешно, то при входе в систему, она сообщит о создании временного файла подкачки, а в оснастке "Управление дисками" будет видно, что старый системный раздел поменял букву диска на D, а новому (на VHD) присвоена буква диска C;
   4. если, что-то пошло не так, то стоит начать паниковать и бить в бубен :S (шутка, у вас всегда есть бекап системы - шаг 1).
10. Форматируем старый системный раздел (диск D). При этом важно, чтобы ОС послала на SSD команду TRIM.
    

    Как показывают тесты, начиная с Windows 7, при быстром форматировании раздела, ОС сама посылает на SSD команду TRIM, и нет необходимости в "ручном" удалении каждого файла для отправки команды TRIM.

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

11. Перенесите файл подкачки на диск D.
12. Перенесите VHD-файл из 'Z:\VHD\PROJECTOR_PC.VHD' в 'D:\VHD\PROJECTOR_PC.VHD'. Так как сейчас система загружена с VHD, то, для его переноса, надо:
    1. создать на диске D директорию VHD;
    2. загрузится с WinPE (подойдет установочный диск Win7 или Win8);
    3. при появлении окна, предлагающего установить Windows, нажать Shift+F10 (откроется консоль);
    4. определить буквы дисков (для этого можно использовать команду dir /A, последовательно перебирая буквы дисков);
    5. скопировать VHD-файл командой:

       copy D:\VHD\PROJECTOR_PC.VHD E:\VHD\

       (замените буквы дисков на свои);

    6. поменять путь к VHD для загрузки:

       bcdedit /set {GUID} device ^
       vhd=[E:]\VHD\PROJECTOR_PC.VHD

       bcdedit /set {GUID} osdevice ^
       vhd=[E:]\VHD\PROJECTOR_PC.VHD

    7. пометить BCD запись, как запись по умолчанию:

       bcdedit /default {GUID}

    8. перезагрузите систему (закройте консоль, и окно установки Windows).
13. При успешной загрузке, удалите старый VHD-файл: 'Z:\VHD\PROJECTOR_PC.VHD'
14. Удалим запись исходной системы из BCD:
    1. определите её {old_GUID} вызвав bcdedit;
    2. удалите запись:

       bcdedit /delete {old_GUID} /cleanup

15. Переходим к настройке дифференциальных VHD:
    1. создайте две новые записи в BCD (и запишите их GUID: {OverGUID1} для 'Windows VHD 1', и {OverGUID2} для 'Windows VHD 2'):

       bcdedit /copy {current} /d "Windows VHD 1"
       bcdedit /copy {current} /d "Windows VHD 2"

       bcdedit /set {OverGUID1} device ^
       vhd=[D:]\VHD\PROJECTOR_PC_over1.VHD
       bcdedit /set {OverGUID2} device ^
       vhd=[D:]\VHD\PROJECTOR_PC_over2.VHD

       bcdedit /set {OverGUID1} osdevice ^
       vhd=[D:]\VHD\PROJECTOR_PC_over1.VHD
       bcdedit /set {OverGUID2} osdevice ^
       vhd=[D:]\VHD\PROJECTOR_PC_over2.VHD

    2. настроим автоматическое переключение между dVHD при загрузке системы:
       1. откройте редактор групповых политик (Win+R -> gpedit.msc);
       2. зайдите в 'Конфигурация компьютера/Конфигурация Windows/Сценарии (запуск/завершение)';
       3. откройте пункт 'Автозагрузка';
       4. нажмите на кнопку 'Показать файлы...';
       5. скопируйте файл VHD_set_over.bat в открывшуюся папку, предварительно заменив GUID в строках 10, 11, 22 на свои (в 22-й строке указывается GUID основной записи - "Windows VHD");
       6. добавьте этот bat'ник в список автозагрузки в окне 'Свойства: Автозагрузка';
    3. сохраните в корне диска D bat'ники, предварительно заменив GUID's: VHD_first_set_over.bat, VHD_set_parent.bat .

Теперь, для включения "заморозки" достаточно загрузится с WinPE, и в консоли запустить VHD_first_set_over.bat .

Для отключения "заморозки" запустите VHD_set_parent.bat .

Несколько советов

Помните, что если суммарный размер VHD+dVHD превысит размер раздела диска, на котором они расположены, то система упадет, т.к. ей просто некуда будет записывать новые измененные данные. Для предотвращения этого, можно уменьшить размер системного раздела на VHD.

Например, установленная и настроенная система (Windows Embedded 7 + необходимые программы) заняла на системном разделе 2.5 GiB. Система установлена на SSD объемом 64 GiB. Предположим, что для нормального функционирования системы (в режиме 24/7) нужно не более 13.5 GiB свободного места на системном разделе. В данном случае целесообразно уменьшить размер системного раздела до 16 GiB (2.5 + 13.5). В итоге получаем, что максимальный суммарный объем VHD's будет равен: 2.5 (VHD) + 16 (dVHD) = 18.5 GiB, что, с учетом pagefile.sys (~2 GiB) и остальных системных файлов, будет меньше 64 GiB (объем SSD), и система никогда не упадет из-за нехватки места для расширения dVHD на SSD.

Перед заморозкой обновленной системы (на VHD), советую сделать Compact:

Compact - сжатие диска, позволяющее убрать неиспользуемое место в динамических дисках. Как вы знаете, если на динамический диск записать данные, он расширяется. После этого, мы можем удалить эти данные, но размер VHD диска не уменьшится, и в хост системе начнёт неэффективно растрачиваться полезный объём HDD дисков.

Ссылки "в тему"

• Уже упомянутая статья-спаситель: “Disk Mode Write Filter” or “Resetting Differential VHDs”
• Использование дифференциальных дисков VHD в Windows 7
• Как переустановить Windows за 1 минуту
• Native VHD Boot: A Walkthrough of Common Scenarios: Scenario 3: Performing an Advanced Deployment of Native Boot VHDs
• Native VHD Support in Windows 7 (сравнение скорости работы: VHD vs "Bare Metal")
• Альтернатива: Разработка MiniFilter драйвера
• Windows на RAM-диске (описаны способы загрузки различных ОС с VHD)
• Windows Diskless with AoE (how to boot Windows Diskless with ATA over Ethernet Protocol)

Но это еще не всё, если Вы программист, то Вам доступны такие плюшки как:

• Бесплатные сообщения на собственный номер.
• HTTP API, SMTP API.
• Callback - оповещение скрипта на вашем сервере о статусе сообщений.
• Возможность замены отправителя - в качестве отправителя может использоваться латинское название вашего сайта или компании.

SMS.RU очень удобно использовать совместно с Google Apps Script, например, можно легко создать 'Автоматическое оповещение об изменениях статуса почтовых посылок через SMS'.