Category: криминал

Category was added automatically. Read all entries about "криминал".

Учебник по JavaScript, ч.3: Фреймы и окна, кликджекинг

Прочел первый раздел «Фреймы и окна» третьей части («Тематические разделы») учебника по JavaScript.

https://learn.javascript.ru

Часть 3. Тематические разделы (в т.ч. 66 подразделов)

Разделы:

1. Фреймы и окна (3 подраздела)

1.1 Открытие окон и методы window
1.2 Общение между окнами
1.3 Атака типа clickjacking

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

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

Рассказано, как из JavaScript работать с окнами в браузере. Под «окнами» здесь подразумеваются как «всплывающие окна» (по-английски «pop-up») и вкладки браузера, так и содержимое фреймов. Для реализации последних раньше использовали HTML-элементы frame и frameset, но на сегодня их использование не рекомендуется, вместо них предлагается использовать HTML-элемент iframe. Рассказано о механизме блокировки всплывающих окон браузера и о том, как он работает.

В подразделе 1.2 рассказано, как наладить общение между окнами с помощью языка JavaScript и о том, как при этом обеспечивается безопасность с помощью политики одинакового источника (по-английски «same-origin policy»).

В подразделе 1.3 рассказано про способ обмана пользователей, который называется кликджекингом (по-английски «clickjacking»).

https://ru.wikipedia.org/wiki/Кликджекинг
https://en.wikipedia.org/wiki/Clickjacking

Почему об этом способе обмана вообще рассказывается в учебнике по языку JavaScript и почему о нем рассказывается именно в этом месте учебника? Потому что этот способ легко реализовать с помощью скрипта на языке JavaScript вкупе с кодом на языках HTML и CSS на HTML-странице. При этом может использоваться HTML-элемент iframe. В подразделе 1.3 рассказано о методах противодействия этому способу обмана. Чтобы разобраться в том, как работает этот способ обмана и в методах противодействия, нужно понимание работы с окнами в языке JavaScript.

Как работает этот способ обмана? Злоумышленник заманивает пользователя на свою HTML-страницу. На этой странице есть некий элемент интерфейса, на который предлагается нажать, чтобы что-то получить (например, кнопка для скачивания какого-либо файла и тому подобное). Пользователь нажимает мышкой («кликает») на этот элемент интерфейса. Но он не знает, что над этим элементом интерфейса растянут невидимый HTML-элемент iframe, в котором загружена другая HTML-страница.

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

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

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

Естественно, большинство крупных интернет-сервисов типа фейсбука, твиттера и так далее, на сегодня уже защищены от кликджекинга. В подразделе 1.3 рассказано, какие есть способы защиты и как они работают.

Тайна местоположения мобильника

Вопрос из книги Таненбаума про компьютерные сети к главе 1 «Введение», цитата:

21. Операторам мобильной телефонной сети необходимо знать местонахождения мобильных телефонов (и, следовательно, тех, кто ими пользуется). Объясните, чем это плохо для пользователей. Назовите причины, по которым это хорошо для пользователей.


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

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

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

Но откуда базовой сети знать, в какой соте (ячейке) в данный момент находится вызываемый мобильный телефон? Данные о местонахождении мобильных телефонов всех абонентов данной мобильной телефонной сети хранятся на сервере абонентских данных — HSS (Home Subscriber Server).

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

Каковы причины, по которым то, что операторы мобильных телефонных сетей знают о местонахождении мобильников своих абонентов, хорошо для них?

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

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

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

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

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

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

Вероятности в сериале «Менталист»

В первой серии второго сезона сериала «Менталист» (серия называется «Искупление») сотрудники КБР обыскивают помещение, в котором полиция нашла убитую женщину, и между Грейс Ван Пелт (ВП) и Патриком Джейном (ПД) происходит следующий диалог.

ВП — Убийца что-то здесь искал, очевидно.
ПД — И он это нашел?
ВП — Э... невозможно установить.
ПД — Но, судя по всему, искали везде, где только можно.
ВП — Да.
ПД — Значит, скорее всего, они это не нашли, о чем бы ни шла речь.
ВП — Отчего же?
ПД — Если ты ищешь в сотне разных мест, какова вероятность того, что ты найдешь предмет в сотом месте? Маловероятно, так?


Тут мне стало интересно и я решил рассмотреть ситуацию с точки зрения теории вероятностей.

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

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

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

Итак, у нас есть множество мест в данном помещении, в одном из которых жертва убийства могла спрятать некий предмет. Обозначим вероятность того, что жертва убийства спрятала некий предмет в первом месте в данном помещении, латинской буквой x с индексом 1, то есть x1. Соответственно, вероятность того, что жертва убийства спрятала некий предмет во втором месте в данном помещении, обозначим x2 и так далее. Тогда получается, что

x1 + x2 + ... + xn = 1 – p,

где n — количество мест.

Заметим, что исходы нашего случайного эксперимента (исход № 1: жертва убийства спрятала некий предмет в первом месте данного помещения, исход № 2: жертва убийства спрятала некий предмет во втором месте данного помещения и так далее) являются равновозможными, то есть верно следующее:

x1 = x2 = ... = xn,

а если уж они все равны друг другу, то обозначим каждую из этих вероятностей латинской буквой x, тогда наша первая формула упрощается до следующей:

n * x = 1 – p,

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

x = (1 – p) / n.

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

x = (1 – p) / 100.

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

x = (1 – 0) / 100 = 0,01.

Это значит, что при заданных условиях вероятность найти некий предмет, спрятанный жертвой убийства в данном помещении, именно в сотом месте (из ста возможных) равна 0,01. При этом вероятность найти тот же предмет в одном из первых 99 мест равна 0,99.

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

Безопасность DLL

Начало тут:Collapse )
Перевод с английского статьи от 31.05.2018 г. «Dynamic-Link Library Security»:
https://docs.microsoft.com/ru-ru/windows/win32/dlls/dynamic-link-library-security
(На данный момент на этом сайте нет перевода этой статьи на русский, есть только версия на английском.)

Когда приложение динамически загружает динамически подключаемую библиотеку (DLL) без указания полного пути к ней, операционная система Windows пытается найти эту DLL, запуская поиск по четко определенному списку каталогов в конкретном порядке так, как это описано в статье «Порядок поиска DLL» [мой перевод]. Если злоумышленник получит контроль над одним из каталогов из поискового списка каталогов, составленного для поиска DLL, он сможет поместить зловредную копию разыскиваемой DLL в этот каталог. Такую ситуацию иногда называют атакой на этапе подготовки DLL к загрузке [DLL preloading attack] или атака подсадкой двоичного кода [binary planting attack] [под «подсадкой» (planting) здесь подразумевается подброс зловредной копии DLL в нужный каталог системы по аналогии с высадкой саженцев растений в грунт; под «двоичным кодом» (binary) здесь подразумевается файл зловредной копии DLL]. Если система не найдет нужную DLL до того момента, как поиск достигнет каталога, над которым у злоумышленника есть контроль, то системе придется загрузить зловредную копию искомой DLL, которую злоумышленник поместил в этот каталог. Если приложение при этом запущено с правами администратора системы, то злоумышленник сможет достичь успеха в повышении прав [privilege elevation] в данной [local] системе.

Например, предположим, что приложение запрограммировано загружать DLL из текущего каталога пользователя и совершать контролируемое завершение программы при ошибке [fail gracefully], если DLL не найдена. Приложение вызывает функцию LoadLibrary, задав ей в параметре только имя DLL [а не полный путь к ней], что служит причиной того, что система запускает поиск DLL. Предположим, что включен безопасный режим поиска DLL и приложение не использует альтернативный порядок поиска DLL, тогда система будет обыскивать каталоги в следующем порядке:
  1. каталог, из которого загружено приложение;
  2. системный каталог;
  3. системный каталог для 16-разрядных библиотек DLL;
  4. каталог операционной системы Windows;
  5. текущий каталог;
  6. каталоги, перечисленные в переменной среды PATH.

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

Разработчики могут помочь своим приложениям защититься от атак на этапе подготовки DLL к загрузке, выполняя следующие рекомендации:
  • везде, где это возможно, указывайте полный путь [к файлу модуля] при вызове функций LoadLibrary, LoadLibraryEx, CreateProcess или ShellExecute в их параметрах;

  • используйте флаги LOAD_LIBRARY_SEARCH при вызове функции LoadLibraryEx в ее параметре или используйте эти флаги при вызове функции SetDefaultDllDirectories в ее параметре, чтобы сформировать нужный порядок поиска DLL, необходимой процессу, а затем используйте функции AddDllDirectory или SetDllDirectory, чтобы модифицировать сформированный ранее поисковый список каталогов. Подробнее об этом читайте в статье «Порядок поиска DLL» [мой перевод].

    Замечание для пользователей (предыдущих по отношению к свежим на дату написания статьи версиям) операционных систем Windows 7 (вики: с 22.10.2009 г.), Windows Server 2008 R2 (вики: с 22.10.2009 г.), Windows Vista (вики: с 30.11.2006 г.) и Windows Server 2008 (вики: с 12.12.2008 г.): указанные выше в этом пункте флаги и функции доступны на этих системах с момента установки обновления KB2533623;

  • для операционных систем Windows, указанных в замечании выше, с установленным обновлением KB2533623, выполняйте рекомендацию из второго пункта;

  • рассмотрите возможность использования перенаправления DLL [мой перевод] или манифеста, чтобы гарантировать, что ваше приложение использует корректную [не зловредную] DLL;

  • при использовании стандартного порядка поиска DLL убедитесь, что включен безопасный режим поиска DLL. Включение этого режима помещает текущий каталог пользователя позже в очередности хода поиска, увеличивая вероятность того, что операционная система Windows найдет корректную [не зловредную] копию DLL раньше зловредной. Безопасный режим поиска DLL включен по умолчанию в операционных системах Windows, начиная с операционной системы «Windows XP» с установленным пакетом обновления SP2, и этот режим управляется параметром реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode. Подробнее об этом читайте в статье «Порядок поиска DLL» [мой перевод];

  • рассмотрите возможность удаления текущего каталога из стандартного поискового списка каталогов при поиске DLL, это можно сделать посредством вызова функции SetDllDirectory с указанием в ее параметре пустой строки "". Это нужно сделать один раз как можно раньше при инициализации процесса, не перед самым вызовом или после вызова функции LoadLibrary. Имейте в виду, что функция SetDllDirectory воздействует на весь процесс целиком и что множество потоков выполнения, вызывающих функцию SetDllDirectory одновременно, но с заданием различных значений для ее параметра, может послужить причиной неопределенного поведения. Если ваше приложение загружает библиотеки DLL третьей стороны, протестируйте их очень внимательно, чтобы выявить любые несовместимости;

  • не используйте функцию SearchPath, чтобы получить путь к DLL для последующего вызова функции LoadLibrary, пока для процесса не включен безопасный режим поиска. Когда этот режим не включен, функция SearchPath использует не такой порядок поиска, как функция LoadLibrary, и очень возможно, что функция SearchPath в поисках указанной в ее параметре DLL сначала обыщет текущий каталог пользователя. Чтобы включить в разрезе процесса безопасный режим поиска для функции SearchPath, используйте функцию SetSearchPathMode с указанием в ее параметре флага BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Такой вызов этой функции передвигает текущий каталог в конец поискового списка каталогов функции SearchPath на период времени жизни процесса. Отметим, что текущий каталог не удаляется из поискового списка каталогов вообще, так что, если система не найдет корректную [не зловредную] копию DLL перед тем, как она достигнет в поисковом списке каталогов текущего каталога, приложение всё еще останется уязвимым для атаки. Как и в случае с функцией SetDllDirectory, вызов функции SetSearchPathMode должен быть выполнен как можно раньше при инициализации процесса и этот вызов повлияет на весь процесс целиком. Если ваше приложение загружает библиотеки DLL третьей стороны, протестируйте их очень внимательно, чтобы выявить любые несовместимости;

  • не пытайтесь определять версию операционной системы [в которой запущено ваше приложение], основываясь на вызове функции LoadLibrary, которая ищет DLL. Если приложение запущено в операционной системе, в которой эта DLL обоснованно отсутствует [как я понял, некоторые программисты пытаются определить версию операционной системы по отсутствию каких-то DLL, специфичных для определенных версий операционных систем], то нужно учитывать возможность того, что в данной операционной системе присутствует зловредная копия DLL [маскирующаяся под разыскиваемую DLL] в обыскиваемых каталогах, и в таком случае она и будет загружена процессом. Вместо такого способа [определения версии операционной системы] используйте рекомендованную методику, описанную в статье «Определение версии операционной системы».

Утилита «Process Monitor» [вики, с 1996 г.] [по-русски «монитор процессов»] может помочь найти те операции по загрузке DLL, которые могут являться уязвимыми для атак злоумышленников. Эту утилиту можно скачать отсюда:
https://docs.microsoft.com/ru-ru/sysinternals/downloads/procmon
[на момент перевода данной статьи по этому адресу доступна версия 3.53 утилиты от 18.12.2019 г.].

Следующий порядок действий описывает, как использовать утилиту «Process Monitor», чтобы проверить [на уязвимости] операции по загрузке библиотек DLL, выполняемые вашим приложением.

Использование утилиты «Process Monitor» для проверки операций по загрузке DLL, выполняемых вашим приложением
  1. Запустите утилиту «Process Monitor».

  2. В утилите «Process Monitor» включите следующие фильтры:
    • по операции CreateFile;
    • по операции LoadImage;
    • по пути, содержащему .cpl;
    • по пути, содержащему .dll;
    • по пути, содержащему .drv;
    • по пути, содержащему .exe;
    • по пути, содержащему .ocx;
    • по пути, содержащему .scr;
    • по пути, содержащему .sys.

  3. Установите исключение по следующим фильтрам:
    • по имени процесса procmon.exe;
    • по имени процесса Procmon64.exe;
    • по имени процесса System;
    • по операциям, начинающимся с IRP_MJ_;
    • по операциям, начинающимся с FASTIO_;
    • по результату SUCCESS;
    • по пути, заканчивающемуся на pagefile.sys.

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

  5. Проверьте окно утилиты «Process Monitor», в котором будет выведен результатный список процессов с учетом установленных фильтров и исключений, в поисках путей, выглядящих подозрительно, таких как обращение к текущему каталогу пользователя для загрузки DLL. Такой вид обращения может указывать на уязвимость в вашем приложении.

Консультант, телесериал, 2016 год

Порекомендовали этот сериал, когда я упомянул, что мне понравился «Метод» 2015 года с Константином Хабенским и Паулиной Андреевой в главных ролях. И, действительно, тут те же жанровые рамки — детектив, психологический триллер, охота на маньяков, оба сериала российские. Но и различия между ними тоже немаленькие.



Итак, первый сезон сериала «Консультант» из 10 серий снят в 2016 году, в апреле 2017 вышел на экраны. Сюжет сквозной, то есть одна большая история на все 10 серий. 18 июня 2018 года телеканал НТВ объявил (http://www.ntv.ru/novosti/2034783/) о начале съемок второго сезона, тоже из 10 серий.

События сериала разворачиваются в 1989 году, в разгар горбачевской перестройки, по мотивам поисков маньяка Андрея Чикатило (в сериале имена участников изменены). Сериал не документальный, а сугубо художественный и сюжет фокусируется не на маньяке, а на людях, которые его ловили. (События второго сезона будут происходить в начале лихих 90-х).

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

Понравилась игра актеров, особенно исполнителей главных ролей — Кирилла Кяро и Максима Дрозда. Это практически новые Глеб Жиглов и Володя Шарапов. Понравился довольно крепкий сценарий с достаточно закрученной интригой.

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

Отписался от Соболева на Youtube

Отписался от канала популярного видеоблоггера Николая Соболева на Youtube (число подписчиков на сегодня 4,4 млн. человек).

Я вообще чрезвычайно редко отписываюсь от кого-либо. Но тут Николаю вздумалось провести на своих зрителях так называемый «социальный эксперимент», в ходе которого он выдал в интернет 3 июня информацию о нападении четверых хулиганов на себя; на анонимном канале выложил ролик, в котором «избивавшие» засняли, собственно, процесс избиения. Целью эксперимента было показать, как легко сегодня манипулировать общественным мнением. (Наверное, вдохновился историей инсценировки убийства Аркадия Бабченко на Украине, произошедшей 29-30 мая).

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

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

К/ф «Азуми 2: Смерть или любовь», Япония, 2005 г.

О первом фильме был предыдущий пост.

Кратко о событиях первого фильма. Чтобы предотвратить новую гражданскую войну и обеспечить своему господину Токугава Иэясу спокойное царствование, несколько вассалов Токугава создают команду убийц, состоящую из детей, и дают этой команде задание уничтожить троих могущественных даймё, лидеров готовящегося переворота. Из команды убийц выжить удалось только Азуми и её товарищу Нагаре. Задание выполнено только на две трети, так как еще остается в живых последний и самый могущественный даймё по имени Санада Масаюки (реально существовавший исторический персонаж). Убийцы решают идти до конца и всё таки закончить задание.

Роль Шона Огури («Вороны: Начало») расширена и становится одной из главных. Кроме него теперь с убийцами путешествует юная проводница-ниндзя, которую играет Чиаки Курияма [Chiaki Kuriyama], известная по роли Гого Юбари, школьницы-телохранительницы женщины-босса якудза О-Рэн Ишии из фильма «Убить Билла» (эпический эпизод с лю син чуй — металлическим шаром на длинной цепи).

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

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

Человек-масса

Прочел пьесу Эрнста Толлера (Ernst Toller) «Человек-масса» («Masse-Mensch»), опубликованную в 1921 году (перевод с немецкого Осипа Мандельштама от 1923 года):
http://www.rvb.ru/mandelstam/01text/vol_4/02addenda/vol_2/4_252.htm

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

«Не за ухом чесать — ломать фундамент надо.»

«Враг наверху не внемлет
Затейливым речам прекраснодушным.
Мощь против мощи.
Действуйте насильем!»

«Что значит одиночка, отдельных чувств
Рассеянная совесть?
Лишь масса обладает бытием.»

«Я здесь, жена, на голос твой явился.»

«Масса — сплющенный народ.»

«Ты — бедный маршал от намыленной веревки.
Словарь твой скудный: «Смерть» и «Истребить».
Сбрось легкий плащ речей высокопарных,
Он саваном бумажным шелестит.»

«Не различаются по существу
Убийцы на отечественный лад
Или международные убийцы, —
Те ценят голову блаженством сотен тысяч,
Другие — миллионов.»

«Кто убивает по наученью государства —
Тот палач»

«Слушай: не смеют люди убивать друг друга
Ради могучих помыслов своих.
Меркнет правда на стороне убийц.»

(Кстати, вот этим и можно было ответить на пост tema по взрыву в московском метро).