Почему же Плутон больше не планета?

В 1978 году был открыт один из спутников Плутона — Харон. Помимо того, что Харон всего в 8 раз легче Плутона, Харон вращается не вокруг Плутона, а оба небесных тела вращаются вокруг общей точки масс. Помимо того, ситуация Платона усугубилась открытием в 2005 году Эриды — ещё одной карликовой планеты, которая ещё и тяжелее Плутона.

Дилемма

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

Так что же такое планета?

Так, в 2006 году выбрали второй вариант — исключить Плутон из списка Планет и составить определение полноценной планеты как таковой.

Существует всего 3 фактора для определения планеты:

1. Это тело вращается вокруг Солнца.
Вполне логичное правило, исключившее Луну, Ганимеда и другие спутники планет. Всё бы ничего но Плутон вращается именно вокруг солнца.

2. Это достаточно массивное, чтобы иметь шарообразную форму под воздействием собственной гравитации.
Тут тоже проблем нет у Плутона, как и у Луны_

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

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

Ну раз сомнений нет, к чему всё это?

Я никак не собираюсь оспаривать решение, принятое в 2006 году, я лишь хочу сказать, что наука продвинулась с 2006 года и привести некоторые доводы в пользу планеты Плутона.

1. Атмосфера Плутона

Плутон от нас находится неимоверно далеко. Кажется, что он совершенно безжизненный. Как бы нам не казалось, в 2015 году зонд New Horizons прислал фото заката на Плутоне. Все удивились, увидев 20 слоёв атмосферы, которые поднимаются на 1600 километров (Даже выше чем на Земле!). Собственно, Плутон — единственный транснептуновый объект, обладающий собственной атмосферой.

Атмосфера на Плутоне в 100.000 раз слабее Земной, и состоит она в основном из азота. Да, основных надежд, она, конечно, не внушает, однако сам факт её наличия выделяет её на фоне остальных кандидатов.

Что ещё интереснее, Плутон постоянно пополняет атмосферу свежим азотом, следовательно, внутри протекают неизвестные нам процессы, синтезирующие азот на поверхность Плутона.

2. Геологическая активность

Все мы (Ну, или почти все) представляем себе поверхность Плутона мертвую, безжизненную, усеянную кратерами. Так выглядят Эрида, Церрера — типичный пейзаж карликовой планеты. Но фото, присланные New Horizons, буквально говорят обратное: На Плутоне огромное количество горных хребтов, глубоких впадин, каньонов и есть все признаки геологической активности. А некоторые горы достигают в высоту 3-х километров! Это свидетельствует о том, что как минимум 100 миллионов лет назад Плутон был геологически активен. Даже Марс — наш сосед, давным-давно перестал был геологически активным.

Конечно же, для всех этих процессов нужна энергия. Много энергии. На земле эти процессы достигаются за счёт горячего ядра. А для Плутона и солнечный свет не играет почти никакой роли.

Согласно данным New Horizons вполне вероятно, что под коркой замерзшего азота и каменистой поверхности существует жидкий океан — лучшее объяснение трещин на поверхности Плутона.

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

3. Ошибочен ли 3 пункт правил?

Знакомьтесь, это Филипп Мецгер — неофициальный «адвокат» Плутона, планетолог из Университета Центральной Флориды (США). В новом исследовании, опубликованном в журнале Icarus, Филипп сообщает, что этот стандарт (очистка орбиты) классификации планет не подтверждается исследовательской литературой.

Филипп Мецгер рассмотрел научные труды за последние 200 лет и с 1802 года нашел только одну публикацию, которая использовала критерий чистоты орбиты для классификации планет и основывалась на неопровержимых рассуждениях. Более того, спутники, такие как Титан у Сатурна и Европа у Юпитера, планетологи со времен Галилея регулярно называли планетами.

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

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

Прекраснейшее умозаключение

Система Плутон-Харон удовлетворяет определению двойной планеты. На настоящий момент это единственная пара тел в Солнечной системе, которая может претендовать на такой статус. С момента открытия Плутона в 1930 году и вплоть до 1978 года Плутон и Харон считались одним и тем же небесным телом.

Немного странно лишать все маленькие планеты на право называться планетами. Даже если так посмотреть, Юпитер тоже влияет на Солнце и центр масс находится за пределами звезды. И что же, теперь нам и Солнце исключать из списка звезд только потому, что Юпитер оказывает на него влияние?) Конечно же нет. Ученых, которые приняли решение о Плутоне в 2006 можно понять — и требовалось ну какое-то решение. У нас нет проблем с такими планетами-гигантами как Юпитер или Сатурн, а вот с маленькими — бывают заминки.

У нас есть традиция: каждые полгода перед тем, как провести конференцию DotNext, мы публикуем на Хабре десять докладов с предыдущей конференции, которые особенно понравились участникам.

Сейчас до осеннего DotNext остаются считанные дни (он пройдёт 3–4 ноября в онлайне, 20 ноября в Москве с возможностью онлайн-просмотра). Так что публикуем десятку с весеннего. Как обычно, в тексте доклады расположены от десятого места к первому — для максимальной интриги.

10. Гибридная архитектура: слияние микросервисов в монолит по необходимости

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

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

Отвечает на этот вопрос Станислав Сидристый, которого участники прошлых DotNext хорошо знают по его докладам о «кишочках».

9. Как написать высокопроизводительный драйвер базы данных

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

Павел Тупицын помогает залезть поглубже и узнать: как вообще мы общаемся с нашей БД? Как работает драйвер (клиент), как его спроектировать и реализовать? В докладе раскрыты все шаги — работа с TCP-сокетами, формат сообщений, сериализация, отказоустойчивость, распределение ресурсов и много другое. Прослушав его, вы узнаете всё необходимое, чтобы написать свой драйвер или спроектировать клиентский протокол для новой базы данных.

8. Kafka: от теории к практике

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

1. Внутреннее устройство Kafka
2. .NET-драйвер к Kafka
3. Сравнение с RabbitMQ
4. Грабли (куда же без них) и best practices

7. Миграция с MS SQL в PostgreSQL, когда нужно ещё вчера

Станислав Флусов ранее уже рассказывал на DotNext о миграции приложения с MS SQL на PostgreSQL. Однако за прошедшее время вопрос сталь лишь актуальнее, и многим понадобилось проделать такую миграцию «ещё вчера».

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

6. Exactly-once в микросервисной среде

Какие две вещи в распределённых системах самые сложные?

2. Доставка строго один раз.
1. Гарантированный порядок сообщений. 
2. Доставка строго один раз.

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

Проблема решается за счёт проектирования идемпотентных сервисов. Артем Рудневский рассказал о том, как решались эти проблемы на примере высоконагруженного сервиса, и как в этом помогали Kafka и Redis.

5. Ordering the Chaos: Cleaning Logs and Ordering Events in Microservices

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

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

В итоге ситуация оказывается такой непростой, что Адам Фурманек начал доклад о ней с философского вопроса «Что такое время?» — но не просто обозначил проблему, а рассказал, что помогает с ней справляться.

4. Откуда что взялось в C#

Известно, что языки программирования очень влияют друг на друга. C# и много что «подсмотрел» в других (его даже называли «копией Java»), и сам много что показал другим (такие фичи, как LINQ и async/await, стали активно заимствовать). 

Из доклада можно узнать, когда на самом деле придумали обобщённое программирование, поддерживает ли C# ленивые вычисления и можно ли посчитать производную с абсолютной точностью. Зачем разработчику всё это знать? Помимо простого любопытства, это помогает ещё и понять внутреннюю логику языка, объясняет, какие задачи решались при внедрении какой-то фичи.

Для такой темы нужен спикер, который активно взаимодействовал с разными языками на протяжении многих лет, и здесь именно такой: Марк Шевченко пишет на C# уже почти два десятилетия, а на других языках вроде C++ начал писать ещё раньше.

3. Атакуем цепочку поставок

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

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

2. Обработка XML-файлов как причина появления уязвимостей

И снова о безопасности, но тут в неожиданном ракурсе: поднимите руку, кто в вопросе уязвимостей думает про XML? А между тем дефекты безопасности, возникающие при обработке XML-файлов, хитры. Почему блог, развернутый на вашей машине, может стать причиной утечки данных? Почему при обработке картинок приложение начинает отправлять сетевые запросы? 

Сергей Васильев разбирает, как обработка XML-файлов связана с дефектами безопасности, что такое XXE и XEE, и каким образом можно защититься от них.

1. Поговорим о хэш-функциях

И, наконец, лидер — доклад Анатолия Жмура. 

Казалось бы, что и зачем вообще говорить .NET-разработчикам в хэш-функциях? Общее представление у всех есть, пользоваться ими при необходимости могут, что ещё нужно-то?

Ну давайте тогда такой вопрос на засыпку. А какое вообще точное определение у термина «хэш-функция»?

То есть в этом докладе многие узнали что-то новое и интересное для себя прямо начиная со вступления.

Надеемся, вы нашли здесь что-то интересное для себя. И если это так, то почти наверняка найдёте и на следующем DotNext — и если поучаствуете в нём, сможете не просто смотреть видео, а задавать вопросы спикерам и общаться с другими участниками. Напоминаем, он пройдёт 3-4 ноября (онлайн) и 20 ноября (Москва+онлайн), все подробности и билеты — на сайте.

Мы в Bimeister любим процессы.

А за что ж их не любить, в самом деле? Хорошо отлаженный процесс создает эффект «оно само»: каждый его участник в любой момент времени точно знает, что и в каком порядке ему нужно делать. За его ходом достаточно приглядывать и иногда нежно подталкивать, если кто-то забуксовал.

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

Привет тебе, читатель Хабра! Я Маша Демченко, системный аналитик компании Bimeister, и в своей первой статье я хочу рассказать о нашем опыте выявления и преодоления сложностей в процессе согласования требований к ПО.

Почему потребовались изменения процесса

Чтобы успешно преодолевать сложности, сначала их надо себе создать.

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

Таким образом, то, что раньше хорошо работало, работать резко перестало.

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

«Узкое горлышко»

«Узким горлышком» может стать как отдельный человек, так и целое подразделение.

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

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

Если делегирование по каким-то причинам невозможно (прямо сейчас или вообще), то есть ещё один вариант — договориться о пропуске проблемного этапа на временной или постоянной основе.

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

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

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

Много согласующих

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

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

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

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

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

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

Пересогласования при изменении требований

Леди не говорят об этом, и всё-таки оно существует. Требования меняются. Или «всплывают» не выявленные ранее — что поделать, бывает.

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

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

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

Тут же хочется сказать о выявлении и следовании приоритетам. Важно их расставить в самом начале и брать в работу задачи, которые требуется реализовать в ближайшее время. Потому что детально проработанные, но долго лежащие в бэклоге задачи имеют свойство «протухать» (как в техническом плане, так и с точки зрения бизнес-потребности), и при запуске в разработку подлежат обязательному пересмотру на предмет корректировок. Это двойная работа, которой можно избежать. Также опыт показывает, что если задача потеряла свой высокий приоритет, то лучше остановить работу по ней как можно раньше. Жаль затраченных усилий, но так «дешевле»: неизвестно, когда понадобится вернуться к проработке требований и насколько к тому моменту изменятся окружающие условия.

Все только начинается

На самом деле, рано подводить итоги и делать окончательные выводы. Наш рост ещё не завершен, впереди много новых контрактов и клиентов.

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

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

Увидимся в следующей серии!

Прошел почти год с того момента, как я написал свою первую сатью на Хабр. Начал этот путь именно с разбора задания MCTF 2021. Решил продолжить традицию в этом году и написать writeup на интересный таск с MCTF 2022.

Обзор

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

Открывается страница авторизации. Можно пробовать проверить на XSS- и SQL-инъекции, но результата это не даст (еще не время для кавычек). Нужно искать другой путь.

Вспоминаем про название таска — «Dirty logs«.

Попробуем перейти по адресу http://mctf.ru:7777/logs.

Странно, но это сработало, изучим логи и подумаем, что делать дальше…

Проникаем в систему

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

Попробуем ввести его возможный пароль и пройти аутентификацию с кредами v_ozerov/HeadOfTheCity. Удалось попасть в «яблочко» с первого раза.
Креды для входа оказались верными — идем дальше!

А дальше мы попадаем на страницу http://mctf.ru:7777/dashboard.

Изучаем систему

Теперь, когда мы в системе, давайте посмотрим, что тут вообще происходит. Есть какие-то «События«, «Аварии» и «Загрязнение».
По нажатию кнопки «Вывести данные» — выводятся данные (очень логично). Для пользовательского ввода доступно только поле «Дата» в формате даты (и снова логично). То есть ничего кроме цифр даты мы ввести туда не можем.

Обычно такие ограничения реализованы только на стороне клиента, а не сервера, если сайт написан на коленке. Чтобы это проверить, нужно как-то перехватить запрос пользователя, модифицировать его и отправить на сервер — запускаем Burp Suite!

Пробуем модифицировать запросы

Заранее оговорю тот момент, что подробно рассказывать о том, что такое Burp Suite и как им пользоваться я не буду. Это тема целой статьи, да и мануалов в Интернете достаточно. Итак, приступим…
В Burp Suite переходим в раздел «Proxy» и нажимаем «Open Browser«.

Переходим в открывшемся браузере на страницу с дашбордом http://mctf.ru:7777/dashboard (перед этим необходимо пройти авторизацию или просто использовать токен из прошлой сессии).
Затем, когда мы попали на дашборд — начинается самое интересное.

Нажимаем в Burp Suite «Intercept is off«, чтобы сменить режим для перехвата запросов, и в браузере жмем «Вывести данные» в любом из разделов.
Снова открываем Burp Suite и видим в главном окне содержимое нашего перехваченного, еще не отправленного на сервер, запроса.

Жмем в любой из строке тела запроса ПКМ и выбираем «Send to Repeater«.

После этого переходим на вкладку «Repeater» и нажимаем «Send«.

Запрос успешно выполнился, результат в правой части окна. Данная вкладка позволяет изменять содержимое запроса и отправлять его снова и снова (опять логично, это же Repeater).
Как видно из запроса, нам действительно доступен только один параметр — date (дата, которую мы можем выбрать в веб-интерфейсе). Мы можем проверить логику приложения и передать в этот параметр дату, но мы сразу приступим к активной фазе — передадим в параметре date обычную «кавычку«.
Вводим в запрос date=' и нажимаем «Send«.

Результат выполнения запроса выдает нам ошибку обработки команды и полностью подтверждает нашу теорию о том, что пользовательский ввод ограничен только на стороне клиента. Но почему именно кавычку? Пентестеры же любят «пихать» кавычки, а если серьезно, до ввода кавычки у меня не получилось заставить сервер хоть что-то внятное мне ответить. Не стал долго думать и «пихнул» — считаю оправданно!

Готовим payload

Как видно из ошибки, параметр запроса date передается на вход Linux-команде (интерпретатора bash) grep на сервере, которая ищет соответствующий паттерн в определенном файле и выводит результат выполнения Linux-командой echo.

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

На лицо атака типа Command Injection. Проблема заключается в том, что аргумент команды grep, куда попадает наш параметр, экранируется с двух сторон одинарными «кавычками». Необходимо подготовить payload имея следующий паттерн:

grep '<payload_в_date>' /home/server/data/events.txt || echo ""

Из того, что пришло мне в голову — надо как-то выйти за пределы «кавычек» и выполнить произвольную команду. Немного пофантазировав и поигравшись с параметрами, удалось скрафтить следующую конструкцию:

grep '.' *;grep '.' /home/server/data/events.txt || echo ""

где, .' *;grep '. — и есть наш payload.
Следуя логике полученной конструкции, в результате успешного выполнения запроса, нам должно показать содержимое всех файлов в текущей директории и содержимое файла events.txt. Проверяем…
В Burp Suite в тело запроса пишем date=.' *;grep '. , нажимаем «Send».

О чудо! Нам вывели содержимое всех файлов в текущей директории.
Продвигаемся дальше, давайте посмотрим список пользователей в домашней директории /home, для чего в теле запроса пишем date=.' /home/*;grep '.

Получаем localuser и server.

Посмотрим что есть у пользователя localuser — date=.' /home/localuser/*;grep '.

Видим еще две директории: Classified и programs.
Посмотрим что есть в первой директории Classified — date=.' /home/localuser/Classified/*;grep '.

И получаем флаг — MCTF{D@RkZ3r5K-iS_w@1ch1ng}

Заключение

Таким образом, наш боевой payload выглядит следующим образом:
date=.' /home/localuser/Classified/*;grep '., благодаря которому на стороне сервера выполняется команда:

grep '.' /home/localuser/Classified/*;grep '.' /home/server/data/events.txt || echo ""

Надеюсь, что читателям понравится данный writeup. Как и для всех заданий в CTF, не исключаю возможности более быстрого и лаконичного решения. Данная статья — это лишь описание хода моих мыслей при решении.
Тем, кто не смог решить данный таск, желаю не расстраиваться, а взять технику «пихать кавычку везде,где только можно» себе на вооружение!

Если вам понравилась Red Faction 1, то игра в Red Faction 2… вас скорее всего разочарует… Сейчас объясню почему. Начну с сюжета. Я ожидал, что события в Red Faction 2 расскажут нам о том, что происходило на Марсе дальше после победы восстания и прибытия сил EDF (Earth Defence Force). Но сюжет игры резко переносит нас на Землю через неопределённое время в будущем после событий в Red Faction 1*. Помните злого сумасшедшего учёного Акселя Чапека, который ставил опыты на шахтёрах? Он разрабатывал какие-то супер-пупер нанотехнологии. После краха корпорации Ультор эти технологии переходят к Earth Defence Force. У них же эти технологии воруют другие вооружённые групировки на Земле. Игра начинается с того, что вам, в качестве бойца спецназа антиутопического, аля «1984», государства «Содружество», поручается добыть эти технологии по приказу канцлера Виктора Сопота.

После того как вы успешно справляетесь с этим заданием, диктатор Виктор Сопот использует нанотехнологии для создания суперсолдат. В число этих суперсолдат входите и вы. Но через какое-то время Сопот пугается тех возможностей, которые он дал своему корпусу наномодифицированных воинов… и приказывает их всех уничтожить. Вместо них он решает создать армию более тупых и послушных «зомби», которые в игре называются «Обработанные». В результате тотальной зачистки из всей армии наносолдат остаётся только небольшой отряд из 6 человек, в который и входит главный герой по прозвищу Элиас. После предательства со стороны Сопота, Отряд объединяет силы с… Красной Фракцией… Которая каким-то образом оказывается на Земле и тоже борется с режимом Сопота. Как Красная Фракция оказалась на Земле..? Что это за страна такая, Содружество..? Всё это остаётся без ответа. В любом случае марсианский шарм игры утерян. Говорят, что сюжет игры слишком банальный и клишированный. Не знаю, если честно, но проблема в том, что он, в отличие от первой части, как-то не захватывает. Не создаётся ощущение погружения в фантастическую вселенную. Всё как-то… механистично.

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

Первое, что бросается в глаза — это собственно графика. Она ХУЖЕ чем в первой игре. Я сперва думал, что это у меня что-то не так с настройками графики или монитором, но, почитав отзывы на просторах интернета, убедился, что это не я один такой. Важная деталь, вернее важнейшая, и не деталь, а главная особенность — игра была сперва создана для консоли PS2, а потом уже портирована на ПК. И этот порт разрабатывала даже не Volition, а другая компания – Outrage Games. Пишут, что «особенности» графики связаны с этим фактом, с первоначальной ориентированностью на консоли. Графика выглядит… Плохо. Не ужасно плохо, но плохо. Всё какое-то серое, размытое, мыльное. Прицел белого цвета вообще с трудом разглядишь. Фоновые текстуры примитивные. И вообще вторая игра вышла всего лишь через год с небольшим после Red Faction 1, в 2002 году. Наверное, решили ковать железо, пока горячо.

Геймплей стал быстрее и агрессивнее. Но недостаточное быстрее, чтобы считаться «скоростным» (fast-paced). Скорость движения игрока, кажется, стала выше, но не достигает скорости онлайн-шутеров. Получилось, как мне кажется, «ни рыба, ни мясо». Врагов стало значительно больше и они лезут из всех щелей, создавая ощущение хаоса происходящего. Игра стала более ориентированной на ближний бой. Если в Red Faction 1 взять и ворваться в толпу врагов с шотганом было довольно самоубийственно, то в Red Faction 2 такое можно и даже нужно проделать. И это могло бы быть весело, если бы скорость движения была бы немного побольше. При этом AI противников как минимум не вырос по сравнению с прошлой игрой. Враги действуют довольно однообразно. Здоровье теперь имеет свойство самовосстанавливаться с течением времени. Это мотивирует игрока прятаться и отходить назад, что сильно сбивает темп игры, который по идее должен быть довольно быстрым.

Появилось деление на уровни, причём довольно короткие. Уровни эти весьма скучны и линейны. Нет вариативности прохождения, нет желания, да и возможности исследовать пространство. В целом прохождение любого уровня можно свести к простому алгоритму: 1) так, ну и куда здесь нужно идти? 2) А, понятно 3) Ааа! Враги со всех сторон 4) Ааа! 5) Фух, вот уже и конец уровня. Можно сказать, что игра стала более аркадной. Сохраняться по ходу игры теперь нельзя. Сохраняются только чекпойнты в начале каждого уровня. Также игра стала в целом легче. Проблему иногда представляли только боссы, битва с которыми тоже была скучной и однообразной. Больше всего меня порадовало, что я не мог убить босса, высадив ему всю обойму из автомата прямо в голову без шлема и нанозащиты. «Гео-мод», то есть разрушаемость, в игре стал более ограниченным. Теперь гораздо меньше объектов можно уничтожить и пробурить себе путь. Зато сам сюжет игры теперь гораздо больше требует что-то взрывать для прохождения дальше. Но для этого целая технология «гео-мод» не нужна. Можно было бы просто маркировать трещины на стенах, как во многих более старых играх.

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

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

В общем, если бы не бренд Red Faction, то эта игра, по крайней мере для ПК, прошла бы, наверное, почти незамеченной. Играть в неё стоит, если вам очень интересна серия Red Faction в целом, и если вы такой фанат шутеров, что не можете пропустить ни одной игры.

* — Тут некая неразбериха. Википедия пишет, что действие Red Faction 2 происходит в 2080 году, через 5 лет после событий в Red Faction 1. Фанатская вики называет эту же дату. Но если в самой игре зайти в раздел дополнительного контента с артами по игре, то в информации об Элиасе (и других бойцах Отряда) можно увидеть, что он прошёл обработку нанотехнологиями в 2161 году. Наверное, стоит верить информации в Вики, так как события Red Faction: Guerrilla разворачиваются в 2125 году. Наверное, разрабы так спешили с выпуском, что напутали даты..?

P.S. Подумал, что Сити-17 с Цитаделью могли быть вдохновлены городом Сопота.

P.P.S. Интересный факт, как пишет Википедия: «Для озвучивания игры были приглашены некоторые известные актёры, включая Лэнса Хенриксена (в роли командира отряда Молова) и Джейсона Стейтема (в роли водителя и пилота Шрайка)».