Skip to content

RenamerTransformer: транзитивно применять class-level exempt'ы к inner-classes#29

Open
devin-ai-integration[bot] wants to merge 3 commits intomainfrom
devin/1777381422-inner-class-exempt
Open

RenamerTransformer: транзитивно применять class-level exempt'ы к inner-classes#29
devin-ai-integration[bot] wants to merge 3 commits intomainfrom
devin/1777381422-inner-class-exempt

Conversation

@devin-ai-integration
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot commented Apr 28, 2026

Summary

Class-level exempt'ы теперь покрывают вложенные / анонимные / локальные классы exempt-овой outer'а.

Симптом из KurumiDev/Motus prod (Paper 1.21.4):

java.lang.IllegalAccessError: failed to access class o.aq
    from class com.motus.listeners.NetworkTrafficListener
    (o.aq and com.motus.listeners.NetworkTrafficListener
     are in unnamed module of loader 'Motus-3.2-RELEASE.jar' @2cc6b5a8)
    at NetworkTrafficListener.register(...)

NetworkTrafficListener был в config-exempt'ах (com.motus.listeners.NetworkTrafficListener) и остался под своим именем. Но 6 его inner-classes ($1..$5 + $TimeStampedLocation) под правило не подпадали — оно матчит только outer. Renamer перенёс их в o/aq, o/aj, … o/ar. javac анонимные/локальные/private nested classes делает package-private; теперь они в другом пакете чем outer, JEP 181 nest-membership через rename не переезжает, JVM access-check падает.

Это очень типовой паттерн (listeners/builders/config DTO с nested types) — без фикса любой плагин с exempt-овой outer-классой получает то же самое.

Fix: хелпер isInnerOfExempt(ClassNode) смотрит во все четыре источника outer-инфы, которые ASM хранит:

  1. NestHost attribute (cn.nestHostClass) — JEP 181, авторитет современного javac.
  2. EnclosingMethod attribute (cn.outerClass) — для local/anon классов внутри методов.
  3. InnerClasses attribute (cn.innerClasses) — присутствует на всех nested типах, обязателен для binary compat.
  4. Outer$Inner heuristic по имени — fallback на случай если class file прогнали через что-то вычистившее debug-attributes.

Если хоть один из них указывает на exempt-овой класс — этот класс не переименовываем и его члены не трогаем. Вызывается в buildClassMapping, в static/private method loop, в membersAreExempt (защищает virtual-method группы), и в buildFieldMapping (включая синтетические this$0).

Review & Testing Checklist for Human

  • Прогнать существующие test-suite обфускатора (mvn test).
  • Накатить новый jar на Paper-сервер (KurumiDev/Motus pickup через scripts/install-obfuscator.sh) и убедиться что IllegalAccessError на NetworkTrafficListener$* исчез.
  • Проверить что nested record (private static record …) тоже корректно остаётся в exempt'е если outer exempt — TimeStampedLocation в нашем тест-случае именно такой.

Notes

На Motus prod jar после фикса: все 7 NetworkTrafficListener-classов остались в com/motus/listeners/* ($1..$5, $TimeStampedLocation, outer). До фикса они становились o/aj..o/ar и валили JVM при первом обращении. com.motus.* классы вне exempt-списка по-прежнему уезжают в o/* — обфускация для всего остального не ослабла.

isInnerOfExempt пробегает 4 источника пер-классу один раз, без рекурсии — стоимость линейная по числу nested-attribute записей в class file (обычно 1–4). Для не-inner классов выходит после первой null-проверки.

Link to Devin session: https://app.devin.ai/sessions/b00b5612c5f34ff89c656aab7111ced1
Requested by: @KurumiDev


Open in Devin Review

Симптом из KurumiDev/Motus@prod (Paper 1.21.4):

    java.lang.IllegalAccessError: failed to access class o.aq from
    class com.motus.listeners.NetworkTrafficListener (o.aq and
    com.motus.listeners.NetworkTrafficListener are in unnamed module
    of loader 'Motus-3.2-RELEASE.jar' @2cc6b5a8)
        at NetworkTrafficListener.register(...)

NetworkTrafficListener был в config-exempt'ах
('com.motus.listeners.NetworkTrafficListener'), поэтому остался под
своим именем в com.motus.listeners.*. Но его 6 inner-classes
($1..$5 + $TimeStampedLocation) под exempt-правило не подпадали:
правило матчит только outer класс. Renamer переименовал их в o/aq,
o/aj, ..., o/ar — переехали в пакет 'o'. javac компилирует
анонимные/локальные/private nested classes как package-private; теперь
они в другом пакете чем outer, JEP 181 nestmate-membership через
переименование не сохраняется как нужно, JVM access-check падает.

Аналогичная проблема могла бы вылезти на любом плагине у которого
exempt outer class содержит nested types — в production это очень
типовой паттерн (listeners, builders, config DTOs).

Fix: при rename-mapping считать класс exempt'ом если у него exempt
outer/nest host. Источники outer-info ASM хранит в четырёх местах,
проверяем все:

  1. NestHost attribute (cn.nestHostClass) — JEP 181, авторитетный
     источник для современного javac;
  2. EnclosingMethod attribute (cn.outerClass) — для local/anon
     классов внутри методов;
  3. InnerClasses attribute (cn.innerClasses) — присутствует на всех
     nested типах, обязателен для binary compat;
  4. Heuristic 'Outer$Inner' по имени класса — на случай если
     class file прошёл через обфускатор/proguard который вычистил
     debug-attributes.

Хелпер isInnerOfExempt() добавлен и вызывается:
  - в buildClassMapping (skip переименования имени класса);
  - в static/private методном лупе (skip переименования членов);
  - в membersAreExempt (защищает virtual-method группы, которые
    касаются inner класса exempt-овой owner'а);
  - в buildFieldMapping (skip переименования полей, в т.ч.
    синтетических this$0 / this$1).

Verified: - Свежий Motus prod jar: все 7 NetworkTrafficListener-классов
    остались в com/motus/listeners/* ($1..$5,
    $TimeStampedLocation, outer); до фикса они становились
    o/aj..o/ar.
  - mvn -P prod clean verify: BUILD SUCCESS, 31/31 unit-тестов pass.
  - Никаких регрессий в обфускации НЕ-inner Motus-классов: все
    com.motus.* классы вне exempt-списка по-прежнему уезжают в o/*.
Co-Authored-By: kurumidev <darkegor.10@gmail.com>
@devin-ai-integration
Copy link
Copy Markdown
Contributor Author

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment and CI monitoring

devin-ai-integration[bot]

This comment was marked as resolved.

…pinning

Devin Review (PR #29) указал на дыру: isInnerOfExempt смотрел только
на config-rule и annotation-driven exempt'ы, но buildClassMapping
пинит классы ещё по двум причинам:

  1. resource references (referenced.contains(cn.name)) — например
     класс из plugin.yml#main, paper-plugin.yml, META-INF/services;
  2. exempt super-types (hasExemptSuperType) — например
     '* extends JavaPlugin' через PaperPluginCompat.

Каноничный пример: Bukkit/Paper main-класс (extends JavaPlugin,
прописан в plugin.yml) почти никогда не попадает в config-exempt'ы,
потому что и так пинится через два других канала. До этого фикса
любой 'new BukkitRunnable() { ... }' внутри main-класса генерил
inner class, который Renamer переносил в 'o/*' — и main класс при
обращении к нему получал тот же IllegalAccessError, что и Motus.

Fix: pre-compute pinnedClasses set в начале buildClassMapping
(referenced ∪ class-exempts ∪ annotation-exempts ∪ super-type-exempts
∪ module-info), потом проверяем inner-of-pinned против него.

Inner-of-exempt (узкая версия) сохранена для static/private method и
field renaming loops — там нужна именно exempt-семантика
(не трогаем members), а не pinned (resource-pinned класс при этом
своих members всё равно теряет, и его inner может тоже).

Verified: - 32/32 unit-тестов pass.
  - Свежий Motus prod jar: NetworkTrafficListener остались в
    com/motus/listeners/* (всё как в PR #29).
  - mvn -P prod clean verify: BUILD SUCCESS.
Co-Authored-By: kurumidev <darkegor.10@gmail.com>
devin-ai-integration[bot]

This comment was marked as resolved.

Devin Review (yellow): для pre-Java-11 classfiles без NestHost
attribute многоуровневое вложение типа Outer$Inner$Deep ловилось
неправильно — lastIndexOf('$') возвращал 'Outer$Inner', а в
pinnedClasses был только 'Outer' (Outer$Inner был лишь пропущен в
rename через ту же проверку, в pinned set его никто не клал). В
итоге Deep уезжал в другой пакет, package-private доступ ломался.

JDK 11+ это маскировал через NestHost (всегда указывает на самый
внешний класс, а он в pinned), но на старых classfiles фикс был
дырявый.

Fix: вместо lastIndexOf('$')+if крутим while-цикл с
lastIndexOf('$', dollar - 1) — проверяем все '$'-сегменты от самого
длинного к самому короткому. Применил к обоим хелперам.

32 теста pass.

Co-Authored-By: kurumidev <darkegor.10@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant