Among Us: ProGuard editon — ищем предателя cреди библиотек

Всем proguard/r8 джедаям посвящается

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

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

Для начала решил посмотреть итоговый конфиг, который после сборки приложения можно найти тут: app/build/outputs/mapping/release.configuration.txt. На реальном проекте он как правило огромный, строк эдак на 2к+, поэтому смотреть его глазами почти бесполезно. В таких ситуациях выручает ProGuard Playground, куда можно загрузить свое приложение, итоговый конфиг и посмотреть к каким файлам какие правила применяются. А еще там есть подсветка синтаксиса ;)

С целью сэкономить время, начал вырубать прямо блоки правил, попутно сверясь с ярлыком keep, на классе который точно должен быть обфусцирован. Спустя некоторое время предатель был найден:

# The proguard configuration file for the following section is ../.gradle/caches/transforms-3/c5544aa6160a86b5bbd5281ae05a46a2/transformed/jetified-customtabs-2.0.0/proguard.txt

-keep public class * {
  public protected *;
}

# End of content from ../.gradle/caches/transforms-3/c5544aa6160a86b5bbd5281ae05a46a2/transformed/jetified-customtabs-2.0.0/proguard.txt

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

./gradlew :app:dependencyInsight --configuration releaseCompileClasspath --dependency customtabs

В результате получаем что-то вроде:

saschpe.android:customtabs:2.0.0 
\--- com.yet.another.lib:utils:3.21.2 
     \--- releaseCompileClasspath

А вот и наша зависимость, которая использует проблемную библиотеку — com.yet.another.lib:utils. Дальнейшие разговоры с поставщиком этой библиотеки лежат за рамками статьи.

Ну и ради интереса зашел посмотреть на проблемную библиотку и понять сталкивался ли кто-то с плохой обфускацией или нет. Оказалось что о проблеме знают и автор вроде как даже выкатил решение. Хотя на текущий момент в master-ветке все еще лежит тот самый заветный файл с правилом, почти полностью отрубающим ProGuard/R8.

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