Система для работы с чарниками для ролевых игр

Оригинал поста на хабре

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

На самом деле речь идёт про это:

Автоматизированное тестирование ботов для Telegram

Оригинал поста на хабре

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

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

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

Конечно, можно зарегистрировать дополнительного бота для тестирования, но это вариант кривой и некрасивый. Обращение ко внешнему апи во время тестов, заглушка, которая не даст общаться с ботом кому попало, ограничение на скорость отправки сообщений раз в секунду… Если слать сообщение раз в секунду, то граф из каких-то 60 вершин будет тестироваться уже больше минуты! И я уже не говорю о том, что у нас нет никакой возможности смоделировать возросшую нагрузку на бота, при которой он упрётся в ограничение в 30 сообщений в секунду… В общем, я понял, что опять придётся делать что-то своё.

Сложно о простом - ESLint в команде

Оригинал поста на хабре

Маленькое введение. Скорее всего этот пост будет интересен только тем, кто знает, что такое ESLint, но всё же сделаю небольшую вводную - а то сам сильно расстраиваюсь, когда открываю публикацию, и она начинается словами “уже 10 лет мы используем ххх, о котором вы конечно же знаете, а написать мы решили про xxx.yyy, что никто никогда не делал, но наверняка это очень круто”.

Итак, ESLint это крутой инструмент, который позволяет проводить анализ качества вашего кода, написанного на любом выбранном стандарте JavaScript. Он приводит код к более-менее единому стилю, помогает избежать глупых ошибок, умеет автоматически исправлять многие из найденных проблем и отлично интегрируется со многими инструментами разработки (привет, Jetbrains, мы любим вас!). Кстати, он, как и другие линтеры, не обязывает вас к одному какому-то конкретному стилю. Наоборот - вы можете выбрать что-то из лучших практик и доработать по своему усмотрению!

Безоблачное мобильное приложение — жизнь без Google Play

Оригинал поста на хабре

Чуть раньше мы с вами думали про то, какие есть альтернативы Google Play, и как можно обходить разные способы блокировки на мобильных приложениях при помощи Google Compression Proxy и тора. Сегодня хочется поговорить о том, можно ли запустить и поддерживать полноценное мобильное приложение на Android без помощи какой либо обязательной внешней инфраструктуры. Рассказывать буду на примере всё того же приложения для просмотра рутрекера. Оно ничем особо не примечательно, но очень наглядно.

Экзамен для будущих «русских хакеров» в Московском Политехе

Оригинал поста на хабре

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

Покемоны замерзли. Как реальная реальность влияет на дополненную и на мобильные приложения в целом

Оригинал поста на хабре

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

Как на самом деле пишут софт в 2016 году

Оригинал поста на хабре

Многие годы софтварные компании скрывали от нас это. Читайте скорее, пока не удалили, и распространяйте как можно шире.

Вы до сих пор думаете, что огромные корпорации обладают большим штатом разработчиков, которые пишут им программный код руками? Наивно. На дворе 2016 год, и правила полностью изменились. Сейчас легко доступны чудовищные вычислительные мощности, о которых 10 лет назад нельзя было и заикнуться. Ваш телефон мощнее, чем вычислительные модули, которые ставили на космические корабли. А человеческое время стоит страшно дорого - в особенности время квалифицированных программистов, которыми, словно пчёлами, якобы набиты офисы технологических гигантов.

Лёгкая интеграция tor в android приложение на примере клиента для рутрекера

Оригинал поста на хабре

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

Для примера я буду использовать приложение для работы с рутрекером - никто не любит код, который работает со сферический конём в вакууме. Раньше это приложение обходило блокировку при помощи Google Compression Proxy - но увы - то ли рутрекер, то ли гугл выпилил возможность авторизации с этой проксёй. Сразу скажу, что, конечно, есть всякие впны и прочее, что вы используете для лёгкого обхода блокировки и просмотра сериальчиков. Но речь здесь идёт не про это. Как вы понимаете, тор можно использовать в мобильном приложении для огромного количества вещей - например, для доступа к веб сайтам в .onion или для реализации особо безопасного мессенджера.

Как подключить библиотеку для работы с Тором

Как собрать с нуля

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

Итак, что у нас есть на эту тему из готового инструментария. Есть особый репозиторий от неких ребят под предводительством Microsoft (ссылка в подвале). Вроде бы у них всё работало - но качество и механизм сборки просто ужасают. А ещё репозиторий устарел на два года. И скомпилированный версии библиотеки там нет, есть только довольно стрёмные инструкции по тому, как собрать её самостоятельно (в стиле - “я делал так, не знаю почему, но без этого ничего не работало”). Впрочем, имеющихся инструкций вполне достаточно для того, чтобы обновить код до актуального состояния и исправить все странные косяки.

  1. Клонируем себе этот репозиторий.
  2. Обновляем там компонент, который отвечает за управление тором - jtorctl. Они использовали форк основного репозитория с правками от briar, но эти правки уже включены в основной репозиторий, так что лучше взять с основного. Можно подключать из maven репозитория, но я такие вещи обычно забираю исходниками - можно сразу посмотреть, прогнать анализ и править на лету баги - проект-то довольно сырой, несмотря на возраст.
  3. Обновляем geoip и geoip6 — базы данных блоков IP-адресов с привязкой к географическому положению каждого блока для версий IPv4 и IPv6 соответственно. Для этого скачиваем на сайте тора windows expert bundle.
  4. Обновляем сам тор (то есть нативную библиотеку). Стандартной общедоступной нет (ну или я плохо искал) - так что идём к ребятам, которые разрабатывают тор и тор браузер под андроид (Orbot и Orfox), берём последний релиз их Orbot и вынимаем оттуда библиотеку. Тор там довольно свежий, что приятно.
  5. Правим руками всё, что перестало компилироваться в нашем проекте. Несколько функций в зависимых библиотеках изменились, но в целом всё интуитивно понятно и поправимо за 5 минут.
  6. Следуя рекомендациям ридми нашего проекта, создаём локальные мавен репозитории и строим из кучи кусков наш проект. Кстати, обратите внимание, что билд скрипт настолько кривой, что в одном месте включает в себя предыдущий релиз себя же. Жуть. Так что рекомендую переписать его заново, простым и понятным языком, чтобы получить на выходе обыкновенную библиотеку aar.

Как собрать из моих наработок

Пункты 1-6 я уже сделал за вас, так что просто соберите библиотеку из моего репозитория, или скачайте её в секции релизов. Ссылка будет в “подвале” поста. Однако обращаю внимание, что правильным будет проверить код и библиотеки на соответствие оригинальным и отсутствие закладок. Не стоит такие вещи добавлять вслепую в свои приложения.

Как перестать волноваться и начать проксировать через тор

Сначала нужно включить тор: 
1
2
3
4
5
6
7
8
9
10
int totalSecondsPerTorStartup = 4 * 60;
int totalTriesPerTorStartup = 5;
try {
  boolean ok = onionProxyManager.startWithRepeat(totalSecondsPerTorStartup, totalTriesPerTorStartup);
  if (!ok)
    Log.e("TorTest", "Couldn't start Tor!");
  }
  catch (InterruptedException | IOException e) {
    e.printStackTrace();
}

Затем подождать, пока он подцепится:

1
2
while (!onionProxyManager.isRunning())
  Thread.sleep(90);

Если всё прошло успешно - ура, он слушает у нас localhost на каком-то случайном порту:

1
Log.v("My App", "Tor initialized on port " + onionProxyManager.getIPv4LocalHostSocksPort());

Но это пока не всё. У нас теперь есть тор, который слушает порт в качестве Socks4a прокси. Однако далеко не все стандартные библиотеки умеют работать с Socks4a. Там из соображений анонимности требуется, чтобы резолв хоста происходил на прокси, а не ранее. Не знаю, какие из стандартных библиотек это умеют, и у меня был код, написанный с Apache HttpComponents. Я уже писал ранее, почему их можно использовать, да и данный пост не про то. Если вы хотите, то можете реализовать то же самое на любой другой библиотеке.

Итак, для использования httpComponents нам нужно переписать ConnectionSocketFactory и SSLConnectionSocketFactory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public class MySSLConnectionSocketFactory extends SSLConnectionSocketFactory {

    public MySSLConnectionSocketFactory(final SSLContext sslContext) {
        super(sslContext);
    }

    @Override
    public Socket createSocket(final HttpContext context) throws IOException {
        return new Socket();
    }

    @Override
    public Socket connectSocket(
            int connectTimeout,
            Socket socket,
            final HttpHost host,
            final InetSocketAddress remoteAddress,
            final InetSocketAddress localAddress,
            final HttpContext context) throws IOException {
        Args.notNull(host, "HTTP host");
        Args.notNull(remoteAddress, "Remote address");
        InetSocketAddress socksaddr = (InetSocketAddress) context.getAttribute("socks.address");
        socket = new Socket();
        connectTimeout = 100000;
        socket.setSoTimeout(connectTimeout);
        socket.connect(new InetSocketAddress(socksaddr.getHostName(), socksaddr.getPort()), connectTimeout);
        DataOutputStream outputStream = new DataOutputStream(socket.getOutputStream());
        outputStream.write((byte) 0x04);
        outputStream.write((byte) 0x01);
        outputStream.writeShort((short) host.getPort());
        outputStream.writeInt(0x01);
        outputStream.write((byte) 0x00);
        outputStream.write(host.getHostName().getBytes());
        outputStream.write((byte) 0x00);

        DataInputStream inputStream = new DataInputStream(socket.getInputStream());
        if (inputStream.readByte() != (byte) 0x00 || inputStream.readByte() != (byte) 0x5a) {
            throw new IOException("SOCKS4a connect failed");
        } else
            Log.v("SSLConnectionSF", "SOCKS4a connect ok!");
        inputStream.readShort();
        inputStream.readInt();

        SSLConnectionSocketFactory sslSocketFactory = SSLConnectionSocketFactory.getSocketFactory();
        SSLSocket sslSocket = (SSLSocket) sslSocketFactory.createLayeredSocket(socket, host.getHostName(), host.getPort(), context);
        prepareSocket(sslSocket);
        return sslSocket;
    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public class MyConnectionSocketFactory implements ConnectionSocketFactory {

    @Override
    public Socket createSocket(final HttpContext context) throws IOException {
        return new Socket();
    }

    @Override
    public Socket connectSocket(
            int connectTimeout,
            Socket socket,
            final HttpHost host,
            final InetSocketAddress remoteAddress,
            final InetSocketAddress localAddress,
            final HttpContext context) throws IOException, ConnectTimeoutException {

        InetSocketAddress socksaddr = (InetSocketAddress) context.getAttribute("socks.address");
        socket = new Socket();
        connectTimeout = 100000;
        socket.setSoTimeout(connectTimeout);
        socket.connect(new InetSocketAddress(socksaddr.getHostName(), socksaddr.getPort()), connectTimeout);


        DataOutputStream outputStream = new DataOutputStream(socket.getOutputStream());
        outputStream.write((byte) 0x04);
        outputStream.write((byte) 0x01);
        outputStream.writeShort((short) host.getPort());
        outputStream.writeInt(0x01);
        outputStream.write((byte) 0x00);
        outputStream.write(host.getHostName().getBytes());
        outputStream.write((byte) 0x00);

        DataInputStream inputStream = new DataInputStream(socket.getInputStream());
        if (inputStream.readByte() != (byte) 0x00 || inputStream.readByte() != (byte) 0x5a) {
            throw new IOException("SOCKS4a connect failed");
        } else
            Log.v("SSLConnectionSF", "SOCKS4a connect ok!");
        inputStream.readShort();
        inputStream.readInt();
        return socket;
    }
}

Использовать эти фабрики легко и просто. Для этого нужно создать HttpClient, который использует эти библиотеки:

1
2
3
4
5
6
7
8
9
10
11
public HttpClient getNewHttpClient() {

     Registry<ConnectionSocketFactory> reg = RegistryBuilder.<ConnectionSocketFactory>create()
             .register("http", new MyConnectionSocketFactory())
             .register("https", new MySSLConnectionSocketFactory(SSLContexts.createSystemDefault()))
             .build();
     PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(reg);
     return HttpClients.custom()
             .setConnectionManager(cm)
             .build();
 }

И указать ему наш прокси сервер:

1
2
3
4
5
HttpClient cli = getNewHttpClient();
 int port = onionProxyManager.getIPv4LocalHostSocksPort();
 InetSocketAddress socksaddr = new InetSocketAddress("127.0.0.1", port);
 HttpClientContext context = HttpClientContext.create();
 context.setAttribute("socks.address", socksaddr);

Всё, теперь мы можем использовать тор так же, как если бы делали обыкновенные запросы. Более того, мы можем так же обращаться и к веб сайтам .onion.

Результат

Получившийся код я использовал в своём приложении для рутрекера. Да, инициализация тора занимает около 20 секунд, и страницы грузятся не так быстро - но зато мы гарантированно проходим блокировку. А все ресурсы, которые не блокированы, подгружаются через обычное соединение. Можно было бы остальные ресурсы пропускать через Google Compression Proxy, но многие жаловались, что у них заблокирован этот прокси - так что я не стал этого делать. Конечно, в приложении можно было бы ещё много всего сделать - например, кэшировать статику на телефоне для экономии трафика и более быстрой работы - но это не столь критично, да и приложение я писал скорее для примера.

Заключение

Тор на андроиде - классная и удобная штука, которая достаточно работает, и её действительно можно использовать в своих приложениях. Кстати да, есть гораздо более лёгкий способ это делать - просто требовать установки Orbot, который сам поднимет вам тор. Но мне не нравятся зависимости одних приложений от других, да и 3 лишних мегабайта не так критичны в размере приложения. Так что если кому понравилось моё решение - используйте, делайте пулл реквесты, и да пребудет с вами свобода.

Ссылки:

  1. Исходная библиотека;
  2. Моя сборка библиотеки;
  3. Приложение для рутрекера;
  4. Guardian Project - ребята, которым мы обязаны наличием нативной тор библиотеки.

О чём молчит Google и почему вам стоит использовать Apache HttpComponents в Android

Оригинал поста на хабре

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

Введение

Если вы разрабатываете под Android, то наверняка сталкивались с тем, что открываете вы своё приложение, которое отлично работало несколько лет, и тут внезапно оказывается, что Apache httpComponents стали deprecated, и их не рекомендуется использовать. Сначала давайте разберём, что же произошло, а потом сделаем выводы, что делать.

Что произошло

Слишком далеко закапываться я не стал, однако много интересных вещей можно получить из рассылки org.apache.hc.dev и джиры Apache. Например, факт что:
Android включал в себя старый pre-beta релиз библиотеки
Более того, на протяжении всей истории версия библиотеки не менялась, и если включаете у себя apache legacy, то это всё та же pre-beta.

Подтверждение можно прочитать тут.

“Подтверждение на английском:

1
Google Android 1.0 was released with a pre-BETA snapshot of Apache HttpClient. To coincide with the first Android release Apache HttpClient 4.0 APIs had to be frozen prematurely, while many of interfaces and internal structures were still not fully worked out. As Apache HttpClient 4.0 was maturing the project was expecting Google to incorporate the latest code improvements into their code tree. Unfortunately it did not happen. Version of Apache HttpClient shipped with Android has effectively become a fork. Eventually Google decided to discontinue further development of their fork while refusing to upgrade to the stock version of Apache HttpClient citing compatibility concerns as a reason for such decision. As a result those Android developers who would like to continue using Apache HttpClient APIs on Android cannot take advantage of newer features, performance improvements and bug fixes.
Google просто забил на проблему
Разработчики из Apache активно работали над библиотекой, но назначенные им менеджеры Google не отвечали месяцами, менялись, а в конце концов сказали, что это не приоритетная задача, пользователям хватает старой версии, да и вообще надо выкинуть эту библиотеку. В подтверждение - немного из упомянутого мной листа рассылки (работа началась в 2008 году, а в 2010 внезапно проявился новый менеджер):

Новый менеджер признаёт, что задаче не уделяют внимания… Ну и ладно.

1
2
Jesse Wilson commented on HTTPCLIENT-898:
I'm Bob's successor on the Android team. If you've got questions about our use of the HTTP client code, I'll do my best to answer 'em. I regret that we haven't given this code much attention lately; that said I'm happy that it hasn't really needed it.

Тогда же прозвенел первый тревожный звоночек:

Знаете, спустя два года мы решили, что ничего не надо делать.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
I'm quite sorry that Android included an unreleased rev of Apache HTTP client, and I suspect we'll be paying for that mistake for quite a while.

Because of the strict compatibility requirements of our platform, we will be unable to make forwards-incompatible API changes to the HTTP code. Unlike your desktop and serverside users, including the API as a part of the core platform significantly reduces our ability to make API changes.

These days we aren't spending much time on the HTTP client code. Our users seem to be mostly satisfied with the ancient version in the SDK, and have been directing their complaints elsewhere (crypto, locales, XML...).

That said, we do want to figure out a long term strategy for an HTTP client API that will work for both us and the Apache HTTP client team. We're considering a variety of options...

  - Discouraging our users from using the built-in Apache HTTP client,    preferring the JDK's own URLConnection classes. Whether this is feasible depends mostly on whether the new APIs in Java 6 (which we're working on)   will satisfy the use cases that Apache HTTP client has covered for years.

  - Replacing the Apache HTTP client API with a 3rd API in a "com.google"  or "android." package. Such an API would likely be based on parts of your own code, but with a more limited API.

  - Tidying up the version of Apache HTTP that we're already stuck with. This includes deprecating APIs that shouldn't have ever been exposed as  public, and possibly filling in any gaps using newer code from your project.

But none of this work is particularly urgent since we're actively fighting fires in other areas of the core libraries.

Они не могут производит изменения в коде существующей библиотеки из-за несовместимостей? Oh rly? А если вынесут это в свой отдельный пакет на основе кода Apache, то внезапно смогут? Вообще, breaking changes в Android это отдельная тема, выходящая за рамки данной статьи, но чего стоит только ограничение разрешений приложений в шестёрке… При этом ребята из Apache активно старались предоставить максимальную совместимость, и было готовы сделать для этого что угодно. Но увы.

Ребят, у нас мало времени, мы взяли вашу разработку и забили на неё, не беспокойте нас по пустякам.

1
I explained on several earlier occasions that Android doesn't allow binary incompatibilities of any kind (not my rule). I understand that the HttpClient team is more tolerant of binary incompatibilities. While I'm not saying it would be impossible to make these changes in Android, I am saying that it would take a lot of convincing (and time), it would annoy other people who are time-constrained and who have higher priorities, and it could likely fail anyway.

Финал

А дальше библиотеку просто без всяких адекватных объяснений выпилили с официальной рекомендацией использовать HttpUrlConnection. Вот хотя бы что-то, отдалённо похожее на объяснение ситуации от Джесси Вилсона, который был на то время в Dalvik team (к слову, он же и был вторым менеджером Google по связям с Apache. Запомните это имя).

В его статье вы можете увидеть, что среди преимуществ он видит:

  • Кеширование (которое, если надо, реализуется где угодно)
  • Малый вес библиотеки (да, но сомнительный аргумент)
  • Компрессия, которая сохраняет батарейку и ускоряет загрузку (да, но при желании мы можем использовать Google Compression Proxy и через Apache HttpComponents как обычный прокси)
Крайне сомнительные объяснения. Если вы сейчас сидите в шапочке из фольги, то рациональным доводом будет то, что гугл таким образом решил втихую заставить пользователей гонять весь свой трафик через свой прокси… UPD. Как мне справедливо указали, под компрессией имеется в виду не использование GCP, а использование стандартного gzip... Который у Apache есть уже много-много лет. Так что тем более странно.

К сожалению, большинство разработчиков слепо верят Google и сразу считают, что библиотека Apache “плохая”, и нужно бежать выкидывать её из своего кода.

Разработчики из Apache прокомментировали это кратко:

Google has used the project when it suited their goals and screwed us afterwards. There is nothing we can do about it.

Эпилог c OkHttp

Если вы разрабатываете под Android, то наверняка видели рекомендации заменять Apache HttpComponents ныне популярной библиотекой OkHttp от Square.

А вы всё ещё помните милого парня Джесси Вилсона из Dalvik team? А вы знаете, что сейчас он работает в Square? И именно он является создателем OkHttp? Более того, вы знате, что OkHttp начинался как форк куска AOSP (Android Open Source Project), который в свою очередь брал свой код из Apache Harmony?

Так что это и есть по сути создание форка Apache с последующим выкидыванием оригинала из обращения (второй вариант из озвученных ранее Джесси в общении с Apache). Звучит довольно гнусно, не правда ли? Единственное что непонятно - была ли это инициатива Google или самого Джесси. Но поступил он крайне некрасиво, выкинув конкурентов с помощью Google и придя весь в белом со своим решением.

И что же?

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

1. Использовать HttpUrlConnection Рекомендованный подход Google. Действительно имеет смысл, если у вас простое приложение. Но не дай бог вам попробовать сделать что-то не совсем тривиальное. В моей практике таких случая было два - когда я пытался использовать SSL прокси и когда хотел обратиться к некоему айпишнику со своим именем хоста. Обе задачи при помощи HttpUrlConnection реализовать невозможно.

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

3. Использовать legacy библиотеку Да, вы можете продолжать использовать всю ту же древнюю бету, что и раньше. Но зачем? Как быстрое затыкание дырки это решение неплохое, а если нет… То конечно нет. Обидно, что именно такой ответ является наиболее популярным решением на том же stack overflow - люди просто не понимают, что они используют версию библиотеки от 2008 года.

4. Использовать последние версии Apache HttpComponents В плюсах имеем то, что мы продолжаем использовать всё тот же код, не тратя время на переписывание и на изучение новой библиотеки и её багов. Более того, код написанный на HttpComponents будет у вас работать где угодно. Библиотека чудовищно мощная и позволяет вам сделать действительно что угодно. Вопрос - как её подключать? Если просто брать и подставлять в gradle, то выйдет конфликт классов с этой самой древней версией. В релизе 4.3 разработчики apache предлагали использовать специальные постфиксы “HC4” в классах для избегания конфликтов, но работало это как-то очень плохо. Зато к релизу 4.5 они уже рекомендуют другой, единственно логичный выход - использовать перепакованную под другим пространством классов библиотеку, собранную неким товарищем на гитхабе (ссылка ниже). Там, правда, на самом деле версия 4.4, а не 4.5 - но это не так принципиально. А если вас волнует, что вы используете собранную непонятно кем библиотеку (хотя она довольно популярна), то вы всегда можете собрать её сами из исходников. На данный момент я считаю это наиболее правильным выходом из сложившейся дурной ситуации (и сам делаю именно так).

Что дальше?

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

Ссылки

  1. Репозиторий с перепакованной версией httpComponents;
  2. Заметки о релизе 4.5, где рекомендуют использовать этот репозиторий;
  3. Интересные фрагменты переписки ребят из Apache и Google;
  4. Любопытные задачи с комментариями в джире Apache - раз и два.
В процессе написания статьи я общался на эту тему с разработчиком из Apache, который подтвердил мои предположения, но от греха подальше упоминать его здесь не буду.

Хроника взлома Pokemon Go

Оригинал поста на хабре

Введение от переводчика

Перевёл эту историю, так как её посчитали интересной в моей предыдущей статье по поводу взаимоотношений Niantic и разработчиков всякого дополнительного софта. Эта милая история не претендует на самый великий и профессиональный взлом всех времён и народов, но позволяет окунуться в уютную атмосферу open source сообщества, занятого общим делом. Возможно, кто-то вспомнит свои прошлые дни... Автор оригинала признаётся, что он не слишком хорошо разбирается в разработке, но это возможно и к лучшему - хорошо передаётся общая атмосфера без лишних технических деталей. Если вас интересуют именно технические детали, то вы можете походить по ссылкам в тексте или просто разобрать получившееся в итоге API. Да, вас может смутить, что в тексте порой говорится то о создании API, то о его взломе. Имеются в виду два разных API - API самой игры и API, которое делают разработчики для управления игрой извне. Придётся различать их по контексту. Да, так же следует учитывать, что обновления писались в спешке и порой усталым и сонным человеком - некоторые формулировки будут звучать странно. Так же прошу прощение за обилие ссылок, часть из которых уже нерабочая. Формат реддита не очень соответствует формату статьи, но мне показалось, что это будет интересно.

Предыстория

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

Мы не можем просто так взять и сравнить версии приложения до и после обновления, потому что эта переменная уже была в предыдущих версиях API, но сервер её не проверял.

Само итоговое значение переменной неважно, и простой подбор не поможет - нам нужно не значение, а способ генерации “неизвестной 6”.

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

История

04/08/2016 - 00:49: Видимо, изменилась логика и протокол. 04/08/2016 - 01:37: Протокол не изменился, новых хешей не появилось. Возможно, теперь запросы подписываются какими-то криптографическими методами, но мы пока не уверены. 04/08/2016 - 02:07: Становится очевидно, что изменение нетривиально, и реверс инжиниринг может занять много времени. 04/08/2016 - 08:08: Все работают над определением “неизвестной 6”. Все известные данные пока собраны тут. 04/08/2016 - 15:06: Мы подтверждаем, что “неизвестная 6” ответственна за произошедшие изменения. 5 August 2016, 14:00 - Прорыв? Разработчики, кажется, нашли, где генерируется “неизвестная 6”. Теперь нам нужно воссоздать процесс и надеяться на то, что всё заработает. И на то, что именно “неизвестная 6” нам всё сломала. 14:30 - Канал в discord ушёл в приватный режим, потому что наш прорыв присваивают себе другие люди. Меня тоже выкинули из discord, так что апдейтов видимо больше не будет. (16:20) Меня пустили обратно. Мы теперь уверены, что дело именно в “неизвестной 6”. Это славно, иначе вся работа по её воссозданию была бы ненужной. Мы на верном пути. 16:30 - Очень много сложной работы и непонятных слов. Насколько я понял, теперь мы знаем, где создаётся большая часть “неизвестной 6”. Теперь надо понять входные данные для генерации и способы дальнейшего шифрования этой неизвестной. Работы предстоит ещё довольно много... 18:00 - Мы разобрали часть шифрования, и можем теперь частично понять исходные данные. Как только мы разберём всё шифрование, мы сможем повторить его процесс, прогнав через декомпилированный код. 19:30 - Мы ещё на шаг ближе... 20:30 - Прорыв #2: Мы связали вместе два куска кода, отвечающих за генерацию “неизвестной 6”. Мы нашли где вызывается функция шифрования. Как я говорил ранее, теперь у нас есть декомпилированная функция шифрования. 21:15 - Нам осталось сделать две вещи: Привести декомпилированную версию шифрования в человеческий вид. Это кастомное шифрование, и декомпилированный код занял бы около 200 странц текста… Люди работают над этим - медленно, но верно. Не самая сложная часть работы, но трудоёмкая. Определить оставшиеся входные данные. Это может быть довольно трудно… Осталось 3-4 поля, и мы радуемся каждому маленькому прорыву. 22:30 - Никаких новостей, кроме того, что "они работают", но я подумал, что хорошо бы что-то написать про последние сутки. Безумно круто наблюдать за работой программистов с реддита и их совместными усилиями по взлому “неизвестной 6”. К слову, это та самая неизвестная, на которой “сломались” хакеры Ингресса. Но коммьюнити разработчиков Pokemon Go гораздо больше. Некоторые работают над взломом уже 20 часов из тех 24, что произошли с момента изменения API. /u/keyphact уже не спал 40 часов (чувак, серьёзно - пойди поспи). Люди работают целеустремлённо и без устали. Я чувствую, что мы можем это сделать.

Мы нашли ядро создания “неизвестной 6” за какие-то несколько часов. Функции шифрования были декомпилированы и были найдены места их вызовов. Осталось 10% входных данных и нормальная реализация функций шифрования. Но так близко, но столь далеко. Справимся ли мы?

23:30 - Мы поняли большую часть шифрования. Однако до сих не поняли, как хранятся входные данные (протобуффер), это безумно сложно. Это требуется, чтобы опередить оставшиеся входные данные. 01:30 - У нас есть полностью рабочее шифрование! (хотя мы его так до конца и не осознали!) Это можно считать прорывом #3. Осталось справиться с протобуффером.

Это безумно интересно и познавательно и для меня тоже. Я с трудом понимаю, чем занимаются разработчики. Например, что такое “формат протобуффера”? Мне сказали, что оно где-то между входными данными и шифрованием. Оно берёт входные данные, формирует из них некий пакет и отсылает на шифрование.

Теперь у нас есть шифрование, но мы не можем определить входные данные, потому что мы не знаем, как из них формируется пакет. Так что мы делаем свой формат пакета (протобуффера). Постепенно, шаг за шагом… Надеюсь, когда мы разберёмся с протобуффером, то входные данные прояснятся. 03:30 - Никаких особых новостей. Мы работаем и продвигаемся.

Следует упомянуть, что обеспечить работоспособность сообщества было безумно сложной задачей. Это был кошмар без всякого логичного решения, и у модераторов не было на него никакого “хорошего” ответа. Начиналось всё легко и просто - открытый канал на discord, где все могли работать вместе над починкой API. Но чуть позже стало ясно, что всё не так легко и просто…

Количество людей на канале росло и росло. Что в свою очередь приводило к огромному количеству спама, вроде “Когда же будет готово API?” или “Что случилось с API?”. Работать стало невозможно, и нам пришлось ограничить права на постинг сообщений в канал.

Что ещё хуже - некоторые представляли нашу работу как свою собственную и давали сообществу ложные обещания относительно того, когда будет готово новое API. А модераторов спамили запросами на право постинга в канал. Мы решили полностью скрыть канал.

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

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

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

5 August 2016, 13:00 - Вот вам подробное техническое описание нашей текущей проблемы. 13:30 - Никаких особых новостей, мы работаем работу. Есть некоторый прогресс с протобуффером, мы вычленили несколько полей, но осталось пока довольно много непонятных данных. Мы так же разбираем функции шифрования, чтобы полностью осознать, как оно происходит. Реверс инжиниринг это сложная и утомительная работа Так же я хочу ответить на несколько комментариев. Маленький FAQ: Q: Я считаю, что я могу помочь, как это сделать? A: К сожалению, основной канал закрыт для новых разработчиков. Но вы можете помочь в нашем публичном репозитории и делать пулл реквесты. Q: Разработчики должны попробовать x. A: Понятия не имею, о чём вы, но они уже наверняка это пробовали. Если вы уверены, что у вас действительно прорывная идея - отпишите её где-нибудь на discord. 15:30 - Никаких особых новостей, всё ещё работаем работу.

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

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

5 August 2016, 16:00 - мы определили ещё одно поле входных данных! Круто видеть наконец какой-то прогресс. Не надейтесь на решение вот прямо сейчас, у нас осталось ещё одно поле, но мы над ним уже работаем. 17:00 - Мы проверили поле, которое я упоминал ранее - да, всё отлично! Настроение у всех отличное, мы продвигаемся. 18:00 - Думаем, что последнее поле как-то связано с тем полем, которое мы только что взломали. Надеюсь, это как-то поможет. 18:30 - Мы хотим ещё раз повторить, что сообщество взлома API не занимается поддержкой ботов. Мы просто ломаем API. Так что хотим подтвердить, что Niantic может проследить любые MITM приложения, например, те, которые модифицируют броски покеболлов чтобы они всегда были точными. Если вы используете такое приложение, Niantic об этом скорее всего уже знает.

Мы не знаем, будут ли вас за это банить, мы просто удостоверились в том, что Niantic может (теоретически) это определять. Но это нас не заботит, мы занимаемся взломом API.

20:00 - Никаких особых новостей на фронте разработки. Всё ещё работаем над оставшимися входными данными. Мы приспосабливаемся к множеству каналов, через которые общаемся с вами. У нас есть Discord, Twitter, Reddit, этот пост и гитхаб репозитории. Они просто разрываются от сообщений. Однако, внутренняя коммуникация у нас налажена гораздо лучше. Настройка и поддержка взаимодействия порой долга и трудоёмка, но это увлекательно. Приятно знать, что разработчики могут спокойно заниматься своим делом, взламывая API. 23:30 - Я вернулся и жду обновлений, чтобы перевести их с программистского на человеческий. Мы ушли уже далеко, но до конечного пункта назначения ещё дальше. 00:45 - Прогресс, сделанный за последние часы, можно назвать прорывом #4. Мы раскрыли ещё 3 входных поля. Одно из полей является шифрованной (вернее, хэшированной) версией тикета авторизации, в комбинации с GPS положением получается второе поле. Третье тоже как-то связано с тикетом авторизации. “Комбинация” это сильное упрощение того, что там на самом деле. Реальная сложность работы программистов сильно превыше моего уровня понимания. Сейчас мы работаем над оставшимся полем. Или полями. GMT 03:30 - Мы особо ничего ни писали, так как прогресса довольно мало. Мы уже 12 часов пытаемся взломать одно из полей. Мы знаем больше, чем когда начинали, но прорыва пока не было. Мы знаем, что поле не комбинируется с токеном авторизации, однако зависит от сессии (возможно, не напрямую). Мы так же знаем его длину (16 байт). Мы работаем над уточнением информации. Прямо сейчас большинство разработчиков всё же ушли спать. Надо сказать, это заслуженный отдых. Пойду и я посплю.

6 august 2016, 13:00 - Так, теперь это будут чисто мои комментарии. Это единственный настоящий источник информации, остальные это подделки. Теперь я буду говорить Я про себя и ОНИ про разработчиков. Это решение было принято, чтобы убрать лишнее давление на разработчиков.

Пока я спал, ничего особо не произошло, возможно потому, что разработчики тоже спали. Поле, которое доставило нам столько геморроя, заслуживает собственного имени, теперь это будет “неизвестная 22”. Дополнительную сложность доставляет то, что оно привязано к сессии, и данные собирать довольно сложно. Мы разбираем это поле и ещё одно. 14:30 - Никаких новостей, просто хотел ответить на вопрос “как же до сих пор ничего не получилось? Вы же говорили, что осталось 3-4 поля, а взломали уже гораздо больше!”

На самом деле, эти 3-4 поля оказались комбинацией из множества других полей, которые тоже нужно взломать. Нельзя ответить на вопрос, сколько же полей осталось. Мы не хотим создавать ложных ожиданий. Да и не знаем. 17:00 - Прорыв #5: Разработчики выяснили, что “неизвестная 22” не нужна. Один из них ответил на это ожидаемым “Да твою ж мать!”. Сейчас разработчики пытаются собрать демо приложение для проверки этой гипотезы. Они очень взволнованы и молятся. Надо заметить, что даже если вызов API будет успешен, это всего лишь прототип, а не исправление API. Разработчики забили на довольно много полей - например, на поле, которое передаётся только с Android устройств. Чтобы его обойти, разработчики эмулируют использование iOS. Нужно сделать ещё много, чтобы это не работало так стрёмно. 17:30 - Первые версии прототипа не работают.

18:00 - Никаких новостей, я просто хотел рассказать, почему “неизвестная 22” оказалась таким геморроем - у нас появилась рабочая теория по этому поводу. “Неизвестная 22” это случайная переменная, генерирующаяся при инициализации приложения и привязываемая потом к сессии. Разработчики тщательно искали всё, что могло бы повлиять на “неизвестную 22”, до тех пор, пока до них постепенно не дошло, что у неё нет входных параметров. Это просто случайная величина. Я попробую объяснить, почему это было так сложно определить.

Пример из реального мира: Представьте, что мы хотим определить температуру в Нью Йорке. Есть огромное количество значений, которые с ней коррелируют. Например, продажи мороженого. Когда продажи повышаются, температура растёт. Однако, вычислять температуру на основании объёмов продажи мороженого бесполезно. Корреляция не означает причинно-следственной связи. Учитывайте это при чтении про “неизвестную 22”. Сначала разработчики пытались менять токен автризации, и каждый раз, когда они это делали, “Неизвестная 22” так же менялась! Так что они решили проверить, что авторизация влияет на “Неизвестную 22”. Для этого им требовались данные.

Сбор этих данных занял много времени, поскольку им приходилось авторизовываться и выходить обратно. Так же на “неизвестную 22” могло влиять много других полей, включая, например, SessionID, Auth_token, Auth_ticket. Они пытались понять зависимости от каждой из них, до тех пор, пока до кого-то не дошло: у “неизвестной 22” нет входных параметров.

“Неизвестная 22” генерируется случайно каждый раз при старте приложения. Так что Niantic никоим образом не может проверить, какое значение там “должно быть” - ведь оно случайно! Так что туда можно просто пихать всё что угодно. Это пока что теория, но все разработчики придерживаются её. 18:30 - Прорыв #6. Кажется, у нас первый успешный вызов API! Ждите обновлений, подтверждение будет в течении часа. 18:35 - Работает! Поверьте, у меня это вызывает столько же волнения, сколько у вас. 19:00 - Публичный чат в discord пока пуст. Всё ещё ждём обновления от разработчиков. Вы тоже обновляете чат, чтобы так же увидеть ничего? 20:00 - Уже довольно долго не было никакой информации. Однако, они говорят, что работают над реализацией- так что видимо больше ломать нечего. Следующий апдейт должен быть большим, оставайтесь с нами… 20:30 - Они убрали публичный гитхаб. Наверное, куда-то переезжают. Видимо, работа идёт. Обновление: репозиторий закрыт по всяким там причинам копирайта. 22:00 - Уже начинаю сомневаться, но всё ещё верю, что они смогли тогда сделать успешный вызов API. Хотя видимо, они думают, когда, как и что им публиковать. Нелёгкая работа, учитывая то, что им закрыли гитхаб. С самого начала все знали, что у этой работы 2 этапа. Сперва реверс инжиниринг, затем создание нового API. Успешный тестовый вызов API важен, поскольку означает, что работа где-то на середине.

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

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

Здесь я так же буду писать свои собственные мыли, как и в предыдущем комментарии. Я не продвинутый программист, но я был с группой “неизвестной 6” с самого начала. 6 august 2016, 23:00 - Небольшое обновление. Они ищут, как обойти копирайт, чтобы их материалы опять не снесли. Так же они пишут, что работают над реализацией- что значит, что они таки сделали успешный API запрос и уже занимаются рабочей версией API. 00:00 - Они говорят, что остался “последний рывок”, будем надеяться, что это означает что-то хорошее. Их работа затрудняется диким спамом с запросом прав и обновлений. Пожалуйста, просто дайте им кодить! Быстрее они работать не станут, и поверьте, вы сможете прожить ещё один день без API.

Так же некоторые обвиняют разработчиков, в том, что они делают это ради собственной выгоды. Это неправда. Я знаю многих из этих ребят, и они делают это просто ради фана, ради челенджа. Они не собираются никому продавать API. Так же они говорят “То, что некий платный сервис говорит, что у него есть исправление API, не говорит о том, что мы им его продали.” 00:30 - Просто хотел сказать - я ненавижу ботов. 00:45 - Они только что подтвердили, что API работает (НЕ ПОЛНОСТЬЮ). Но они вообще писали не об этом:

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

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

1:15 - Готово, API выпущено! Победа. Разработчики сломали API за 3 дня и 5 часов. Достойное достижение. 1:30 - Это API легко отслеживается, и Niaintic может определить, что вы используете не официальный клиент. Разработчиков это вполне устраивает, и не стоит катить на них бочку. Например, не учитывается высота над уровнем моря. Так же все запросы якобы идут с IOS устройства, что крайне подозрительно, поскольку с очевидностью оно Android… Работы ещё много, но мы получили рабочее API и с этим наше участие в проекте завершено.

1:45 - Пойду-ка я спать. В последние ночи я спал совсем мало. Хочу сказать огромное спасибо всем разработчикам, модераторам и всем остальным, кто принимал участие. И тем, кто терпеливо ждал решения проблемы. Ваша поддержка была удивительна. Неделю назад я не мог и представить, что буду полноценным менеджером сообщества хакеров Pokemon Go. Всем спасибо, /u/DutchDefender

От переводчика

Как вы понимаете, история не окончена, история только начинается. Прислушается ли Niantic к просьбам о улучшениях приложения? Или попробует снова защититься? Хватит ли у сообщества сил, желания и навыков взломать новые способы защиты? Узнаем в скором времени.