OkHttp была создана для прямой работы с верхним уровнем сокетов Java, при этом не используя какие-либо дополнительные зависимости. Она поставляется в виде JAR-файла, так что разработчики могут использовать ее на любых устройствах с JVM (куда мы включаем, конечно, и Android).

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

Ты обратил внимание на метод closeCodeExceptionMessage(int code) класса okhttp3.internal.ws.WebSocketProtocol. И действительно, если просто глянуть на этот метод, кажется будто он выполняет какую-то "магию", но на самом деле это просто возвращение строки.

Взглянем на декомпилированный метод:

• Поясню, что тут происходит:
• На вход подается переменная i
• Если i не находится в диапазоне от 1000 до 5000, метод возвращает сообщение: "Code must be in range [1000,5000): "
• Иначе проверяется ((i меньше 1004 или i больше 1006) и (i меньше 1012 или i больше 2999)). Если оба этих условия выполняются, то возвращается null

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

sb.append("Code ");
sb.append(i);
sb.append(" is reserved and may not be used.");

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

Как видим, код практически не отличается. Да и то, отличия кода из приложения лишь в проделанных оптимизациях со стороны компилятора. Технически же они вообще не отличаются.

Посмотрим где этот код используется. К счастью, таких мест всего несколько:

Ну и пару примеров использования

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

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

=== 02.12.2019, 21:44:17 (1829 ms) [Response] ===

=== 02.12.2019, 21:44:19 (1846 ms) [Response] ===

=== 02.12.2019, 21:44:21 (2141 ms) [Response] ===

=== 02.12.2019, 21:44:23 (1844 ms) [Response] ===

=== 02.12.2019, 21:44:25 (2372 ms) [Response] ===

=== 02.12.2019, 21:44:27 (1729 ms) [Response] ===

=== 02.12.2019, 21:44:29 (2496 ms) [Response] ===

Сравним их с предыдущими

Как видим, промежутки в 2-3 секунды являются отличающимися на самом деле. В среднем промежуток между ответами от 1,7 до 2,5 секунды.

Содержимое самих ответов одинаковое. (см предыдущую статью)

Объект заказа

Помимо сниффинга списка заказов, следует уделить внимание данным, которые передаются при принятии заказа (на экране на месте/в пути)

{
  "user_id": id заказа,
  "point": "0",
  "timestamp": 1575315692,
  "order_data": {
    "FPDATE": null,
    "FOTID": 66770656,
    "FDIAL_T": 1575323459,
    "FLIGHT": "000",
    "FDIAL_S": "2000000010",
    "FTEL": "номер телефона клиента",
    "FA": null,
    "FSTATUS": 21,
    "FDIAL_O": "ORDER_DRI",
    "FAD_ROUTE": [
      "место заказа"
    ],
    "FCOST": цена заказа,
    "FAD_STR": "адрес заказа",
    "FCLI": null,
    "FAD_PO": null,
    "FAD_H": null,
    "FDIS": "i",
    "FDRI_TAXI": "служба такси",
    "FDRI_ID": позывной водителя,
    "FCOST_DATA": {
      "distance": "4161(0) + 0(0)",
      "cost_s": "сумма заказа грн.",
      "Coord": [
        [
          широта,
          долгота
        ],
        [
          широта (точно),
          долгота (точно)
        ]
      ],
      "area": "район заказа"
    },
    "FOT": "служба такси",
    "FOPR": "ID",
    "FID": еще какой-то ID,
    "FDATE": время принятия заказа,
    "FOTW": 1,
    "F0": еще какя-то дата,
    "UHASH": "53",
    "FAD_NOTE": null,
    "FLOCK": null,
    "FDRI": "???"
  },
  "session": "ID сессии",
  "order": номер заказа
}

Из этого можно выбрать данные для навигации c исп FakeGPS. Осталось только придумать, как это реализовать...

Временные промежутки

Если смотреть тупо на даты ответов, то можно определить, что они идут с некоторой закономерностью

========= 13.11.2019, 22:28:18 =========

========= 13.11.2019, 22:28:19 =========

========= 13.11.2019, 22:28:22 =========

========= 13.11.2019, 22:28:25 =========

Из этих 4 дат мы прекрасно видим, что первые 2 идут с разницей в 1 секунду, а последующие с разницей в 3 секунды. Это можно увязать с временем обновления списка заказов. Первые 2 раза обновление происходит быстрее, чем в последующие.

Содержимое ответов

Сразу скажу, я логгировал только ответы со статусом "session". Т.е. непосредственно содержимое сессии.

Типичный ответ выглядит так:

{
    "orders": {// заказы
        "служба такси:позывной": [// список
            {//заказ №1
                "FPDATE": null,
                "FOTID": число (предп. ID заказа),
                "FDIAL_T": число (предп. дата заказа),
                "FLIGHT": "число",
                "FDIAL_S": "число",
                "FTEL": null (предп. номер телефона),
                "FA": null,
                "FSTATUS": 21,
                "FDIAL_O": "ORDER_DRI",
                "FAD_ROUTE": [
                   // массив строк
                ],
                "FCOST": 105, // сумма заказа
                "FAD_STR": "куда ехать (напр. ул. Пушкина, дом Колотушкина)",
                "FCLI": null,
                "FAD_PO": null,
                "FAD_H": null,
                "FDIS": null,
                "FDRI_TAXI": null,
                "FDRI_ID": null,
                "FCOST_DATA": {
                    "distance": "333(0) + 10004(0) + 0(0)",// хз вообще что
                    "cost_s": "105 грн.", // сумма заказа в гривнах
                    "Coord": [// координаты
                        [
                            // массив координат с точностью до 3-х знаков
                        ],
                        [
                            // массив координат с точностью до 5-ти знаков
                        ],
                        [
                           // массив координат с точностью до 7-ми знаков
                        ]
                    ],
                    "area": "район заказа"
                },
                "FOT": "предп. ID службы",
                "FOPR": "предп ID оператора",
                "FID": ID,
                "FDATE": дата,
                "FOTW": флаг,
                "F0": null,
                "UHASH": "07",
                "FAD_NOTE": null,
                "FLOCK": null,
                "FDRI": null
            },
            //еще заказ

//и еще
    "status": [
        {
            "user_id": ID водителя,
            "order": ID текущего заказа,
            "order_data": данные по текущему заказу,
            "point": флаг (значение либо "0", либо null),
            "timestamp": время,
            "session": "ID текущей сессии"
        }
    ],
    "road_from": "visicom"
}

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

{
    "response": "session",
    "data": [
        {
            "fmanid": "ID водителя",
            "session": "ID текущей сессии"
        }
    ],
    "error": "",
    "settings": [
        {

// настройки блокировки
            "block_time": "600"
        }
    ],
    "money": [
        {
            "ftaxi": "служба такси",
            "fdri": "позывной",
            "fservice": "название службы такси"
        }
    ],

//настройки
    "common_settings": {
        "autoget": "5000",
        "autohighlight": "5000",
        "coords": {
            "lat": "широта",
            "lng": "долгота"
        },
        "Taxoid_pA_Check_Enabled": 0,
        "Taxoid_pA_Check_Radius": "500"
    }

Также не совсем понятно присутствие флага номера телефона в списке заказов. Его значение можно узнать только при принятии заказа.

Ничего особо интересного там более нет.

До версии 2.6 запросы на сервер отправлялись циклично. Внутри APK был код, который через каждые N миллисекунд отправлял запрос на сервер. Приложение само запрашивало у сервера данные, следовательно его можно было обмануть. К примеру, "ускорить" время с помощью таких программ, как GameGuardian или GameKiller. В этом случае побеждал тот, у кого больше запросов к серверу.

Разработчики это прекрасно понимали, и начиная с версии 2.6 они перешли на протокол связи в режиме реального времени - проще говоря, WebSocket.

Тут хорошо подходит аналогия с мессенджером: мистер xxx пишет сообщение, и отправляет его мистеру yyy. К сожалению, мистер ххх пишет сообщения очень медленно, но это никак не исправить. Ты не можешь заставить собеседника печатать быстрее, если он не в состоянии это делать. То же самое и с клиентом. Клиент не может заставить сервер отправлять ему сообщения в более ускоренном темпе. Тут-то как раз и появляются флексы с серверами, точнее с их портами. Я не спец в этом деле, не могу сказать, что есть 100% рабочий метод заставить сервер быстрее отсылать сообщения, только если это не скомпрометированный сервер.

Я скажу лишь о тех моментах, которые связаны с получением данных через Socket протокол. Для удобства анализа всё будет представлено в виде Java-кода, а не smali. Java более проста для понимания сложных алгоритмов.

Итак, преступим:

Сначала стоит поискать по ключевому слову "Socket"

Нашло 46 результатов. Теперь еще раз сделаем выборку. На этот раз по слову "taxoid". Там и вовсе 2 класса:

1. c.c.a.d.b.a.l.java

Я изменял эти переменные еще в самом начале изучения Taxoid-а. Объясню, что тут происходит:

Присваиваются несколько переменных.

Класс d.b.b.e объявляется как переменная e

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

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

А где же сокеты?

2. c.c.a.d.c.e.java

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

Здесь:

Устанавливается сокетное соединение с уже данным хостом и портом

Устанавливается таймаут в 10 секунд

Начинается чтение данных с сокетного соединения

Устанавливается флаг коннекта в положение true. Скорее всего, чтобы не коннектиться каждый раз по новой.

А сам адрес, откуда берутся данные:

Круг замкнулся. Осталось только посмотреть, что за данные он отдаёт

Об этом чуть позже.

com/pk/taxoid/activities/AuthActivity.smali - добавлен метод disableDoze(), который добавляет отключение оптимизации Doze Mode, и, в теории, обеспечивает более стабильную работу приложения в фоновом режиме (система не будет выгружать его при малом заряде батареи)

• smali/com/pk/taxoid/activities/NavigationActivity2.smali
• smali/com/pk/taxoid/activities/NavigationActivity.smali
• smali/com/pk/taxoid/activities/SelectLocationActivity2.smali
• smali/com/pk/taxoid/activities/SettingsActivity$FilterPreferenceFragment.smali
• smali/com/pk/taxoid/activities/SettingsActivity.smali
• smali/com/pk/taxoid/widget/LimitedEditText.smali
• smali/ru/yandex/bz.smali

Удалены все тосты (всплывающие сообщения с текстом).

smali/com/pk/taxoid/libs/location/b.smali - изменено дефолтное значение локации с "unknown" на "pinkypieunknownpinkypie". Зачем - непонятно.

И еще такие же:

/smali/d/a/a/a/n/g/l.smali

/smali/d/a/a/a/n/g/r.smali

Удалены ссылки для отправки отчетов об ошибках разработчикам.

Манифест

Заменен ключ Google карт

Добавлены разрешения:

android.permission.SYSTEM_ALERT_WINDOW
android.permission.READ_LOGS
net.dinglisch.android.tasker.PERMISSION_RUN_TASKS
android.permission.BLUETOOTH_ADMIN
android.permission.VIBRATE
android.permission.SYSTEM_ALERT_WINDOW
android.permission.CHANGE_WIFI_STATE
android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
android.permission.ACCESS_NETWORK_STATE
android.permission.USE_FINGERPRINT
android.permission.ACCESS_WIFI_STATE
android.permission.BLUETOOTH
android.permission.WRITE_SETTINGS
android.permission.READ_SETTINGS

Вот и всё. Из значимых изменений, только doze. Остальное - пшик.

• Диалог ввода пароля сделан с помощью готового импланта из приложения AppCloner (Android)
• Приложение зашифровано через MT Manager (Android)
• К приложению применен хук снятия проверки подписи mthook, из того же MT Manager. При этом, в оригинальном приложении нет проверки подписи!
• При запуске приложение фризит (не реагирует на нажатия кнопок) до того момента, пока ты вручную не выдашь все разрешения через настройки

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

Ну что, заглянем внутрь?

Структура мода

И с самого первого взгляда становится ясно, что без бубна тут не обойтись:

К оригинальным папкам со smali, добавилось еще 2:

• smali_classes2
• smali_mthook

Сначала глянем, что же в первой. А в ней есть следующие папки с классами:

andhook/lib/ - множество классов, целью которых являются снятие проверки подписи APK через череду хаков. Но вот в чем прикол - в оригинальном приложении я не нашел даже намёка на ее наличие. Зачем этот хук нужен здесь - не особо понятно. Также внутри andhook/lib/ имеется отдельная папка с названием xposed. При беглом анализе я понял, что это тот же самый хук, только еще и при помощи xposed (для тех, у кого он установлен). Но дела это не меняет.

android/os/Environmenu.smali - изнасилованная копия стандартного класса android.os.Environment. Отличие лишь в добавленной отладке для более лучшего дебага.

com/applisto/appcloner/ - классы, добавленные небезызвестным приложением AppCloner. Все те самые моды, которые можно добавить через него, лежат здесь. Суть в том, что даже если тебе нужно добавить всего 1 фичу в приложение, например тот же пароль на запуск, в приложение интегрируется не только экран с паролем, а ВООБЩЕ ВСЕ ФИЧИ, которые предоставляет AppCloner. Т.е всякие маскировщики, смена икони и названия, автозагрузчики, чистильщики кеша при выходе из приложения, блокировщики сенсоров камеры и т.д. тоже будут вкорячены внутрь, просто будут отключены через специальный файл конфигурации cloneSettings.json (зашифрован)

java/io/ByteArrayOutputStrean.smali - изнасилованная копия стандартного класса java.io.ByteArrayOutputStream. Отличие лишь в добавленной отладке для более лучшего дебага.

С первым дексом разобрались. А что же со вторым (smali_mthook)?

Это тоже обход проверки подписи, встроенный в MT Manager. Просто это более ранняя его версия (появилась чуть более 2-х лет назад). Тот хук, который я описывал в начале, это его приемник (появился чуть более 3-х месяцев назад). Скорее всего человек применил сразу 2 патча, чтоб наверняка.

Ресурсы (разметка, иконки, и т.д.) зашифрованы и складированы в одну кучу в папке /r/. Их анализ не представляется возможным, ввиду огромного количества времени и сил, которое мне придется потратить (не день, не два и не три).

А был ли мальчик?

Перейдём к самой главной папке smali, в которой находится код приложения. Может быть здесь будет нечто интересное, крышесносное, и вообще прям "пушка"? Как бы не так...

Открываем папку, и видим, что очень много smali файлов отличаются между собой на несколько десятков байт. Открываем первый попавшийся файл и нам предстаёт картина маслом:

Содержимое этих файлов идентично. Различается только лишь строка .source. Если в оригинале её значение равно "", то в моде мы видим "SourceFile_xxx". Вместо xxx могут быть абсолютно любые числа. Сделано это умышленно, чтобы всяческие утилиты сравнения файлов считали эти файлы отличающимися. Да, они отличаются, но по факту это лишь пыль в глаза.

Иной мододел, будь он на моем месте, опустил бы руки, сказав "я не знаю", но я-то плюс ко всему еще и разработчик...

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

Для того, чтобы убрать эти строки, нужно написать регулярное выражение. Удобнее всего это делать на regex101.com

Используя следующее регулярное выражение, стоит лишь найти и заменить все совпадения через текстовый редактор с такой функцией (я использую Atom)

В результате я привел 4 тысячи файлов к оригинальному виду:

Делать это вручную было бы сродни самоубийству.

Ну и последнее, пакет приложения был изменен с com.pk.taxoid на com.pk.taxoie, следовательно нужно его переименовать для удобства сравнения.

И еще пара штрихов:

Изменения приложения опишу завтра. Их там не особо много. Скажу лишь одно: этот мод - сборная солянка, помноженная на 1000 и 1 патч для ApkEditor, и накрытая слоем говна от AppCloner.

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

В основном это касается виджетов, Но и некоторые другие классы были изменены.

Список виджетов:

• /smali/com/pk/taxoid/widget/Button.smali - кнопки
• /smali/com/pk/taxoid/widget/FastPanel.smali - панель вверху списка заказов
• /smali/com/pk/taxoid/widget/LimitedEditText.smali - поле ввода радиуса автозахвата
• /smali/com/pk/taxoid/widget/TableFixHeaders.smali - табы

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

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

Изменены такие классы как LocationTrackerService (сервис отслеживания локации), MessagingService (сервис, посылающий сообщения водителям - "У вас новое сообщение") и т.д.

Экран регистрации в приложении и экран прохождения TO реализован в одной активности - RegistrationActivirty, с двумя разными фрагментами (в зависимости от того, какая кнопка нажата)

Сначала скажу о том, что не поменялось с последней исследуемой мной сборки:

Ассеты - без изменений (искл чейнджлог)

Нативные библиотеки - без изменений

Ну а теперь к интересному:

Основные изменения

Приложение переведено на AndroidX вместо устаревших support library. Не прошло и полутора лет. Большинство фактических изменений в коде будут связаны именно с этим. Поменялись имена и пути классов, теги у Layout-ов и т.д. Всё это очень усложняет сравнение.

AndroidX? Support library? Что это за набор букв?

Грубо говоря, AndroidX - это библиотека поддержки от Google, с помощью которой можно использовать новые API на старых версиях Android (например материальный дизайн появился только начиная с Android 5.0, но с помощью данной библиотеки можно использовать элементы этого дизайна и на Android 4.x)

В 2018 Google изменила концепцию разработки этих бибилиотек. Был изменен рабочий цикл разработки, а так же изменила имя пакета с android.support.** на androidx.** и com.google.**

В общем понятно. Если есть вопросы - дорога в гугл и оф документацию.

/smali/a/

/smali/b/

/smali/d/

Эти пакеты несут в себе часть классов из AndroidX и прочих библиотек

/smali/c/ - бывшая часть /smali/com/pk/taxoid/libs

/smali/f/ - бывший /smali/c/

Добавлена библиотека Glide (smali/com/bumptech/glide/) для загрузки изображений из сети. Сама по себе ничего интересного не представляет, но генерирует просто туеву хучу мусорного кода. Я подозреваю, что она используется для загрузки изображений при прохождении TO (теперь его можно пройти прямо через приложение, а не через сайт, как раньше)

Обновлена библиотека okHttp, используемая при запросах на сервер

com/pk/taxoid

activities/NavigationActivity2.smali

Улучшения работы и точности карт

Завтра будет продолжение

Вся магия происходит в классе smali/com/pk/taxoid/libs/d/a/a.smali:

В оригинальный класс добавлено 2 переменных:

Переменная count - это количество обращений к серверу мододела (об этом ниже)

Переменная timestamp это дата обращения. Timestamp это количество миллисекунд прошедшее с 1 января 1970 года. Можешь посмотреть википедию, если хочется больше объяснений.

Внутри существующего метода run() вставлен вызов нового метода setNewTimer()

Если результат выполнения метода doGet() меньше 100, то переменной e присваивается значение 30

Глянем метод doGet()

 public static long doGet() throws Exception {
        if (count >= 600) {
            BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(((HttpURLConnection) new URL("http://taxoid.freeoda.com/?customer=96").openConnection()).getInputStream()));
            StringBuffer stringBuffer = new StringBuffer();
            while (true) {
                String readLine = bufferedReader.readLine();
                String str = readLine;
                if (readLine != null) {
                    stringBuffer.append(str);
                } else {
                    bufferedReader.close();
                    String stringBuffer2 = stringBuffer.toString();
                    count = 0;
                    timeStamp = Long.parseLong(stringBuffer2);
                    return Long.parseLong(stringBuffer2);
                }
            }
        } else {
            count++;
            return timeStamp;
        }
    }

Вот примерная схема работы этого кода:

• если count равно 600 или больше
• Подключаемся к серверу http://taxoid.freeoda.com/?customer=96
• Смотрим, какую строку он выдаёт
• Если строка существует, то сохраняем ее значение в переменную
• Если строка не существует, то создаём ее самостоятельно, ставим count = 0, и присваиваем значение строки в переменную timestamp
• Иначе, прибавляем единицу к count и возвращаем переменную timestamp

Грубо говоря, timestamp устанавливается на сервере, и ты можешь работать ровно до того момента, как он не пересечёт определенную отметку, устанавливаемую мододелом.

Сервер, кстати, до сих пор работает:

Но сама эта проверка ни что иное, как собачий пук, потому что легко убирается всего лишь удалением условия с doGet() в методе setNewTimer()

Прочие изменения

smali/com/pk/taxoid/libs/d/d.smali:

Уменьшен триггер с 0x331 (817) до 0x1 (1)

smali/com/pk/taxoid/libs/i.smali:

Переменная k теперь равна 2000 вместо 0

Переменная n равна 2000 вместо 1000

smali/com/pk/taxoid/widget/FastPanel.smali:

Верхняя панель ввода радиуса автозахвата. Увеличен лимит до 20 000. Важно понимать, что лимит можно сделать хоть 100 000, но работать это будет только в том случае, если это поддерживает сервис.

Вот и все фишки данного мода. Такие дела.

smali/com/pk/taxoid/libs/b/***

smali/com/pk/taxoid/libs/с/***

smali/com/pk/taxoid/libs/e/***

Классы сильно перетасованы. Что-то сказать сложно. Можно утверждать, что это какие-то улучшения работы с сервисом карт от Яндекса, и прочие внутренние изменения

smali/com/pk/taxoid/network/c/b.smali - в запросах к API стала хардкодиться версия приложения. Тупо отдельным параметром:

/smali/com/pk/taxoid/network/retrofit/ApiService.smali - Добавлены методы запросов на сервис регистрации (getCars/getCities/uploadPhoto и т.д)

smali/com/pk/taxoid/services/*** полностью отдан под реализацию логики регистрации в сервисе такси

Местоположение

Хочется остановится подробнее именно на этом изменении. В 2.7 появился отдельный сервис трекинга местоположения. Класс LocationTrackerService является foreground сервисом, который имеет постоянное уведомление в строке состояния. Циклично отсылает данные о твоём местоположении. Хочу отметить, что отправка данных начинается сразу после запуска, еще на главном экране.

Запуск отслеживания идет в методе onStartCommand

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