Automatic resolution of framework & package resource ids

[kosovo0275]

trafficstars

Trimmed all of the extra baksmali flags and reimplemented just the resource resolution, with the addition of automatically parsing and annotating all framework resources as well.

[kosovo0275]

I figured out how to avoid extending BaksmaliOptions in the Config, and consolidated the code that actually parses the framework and package into ResourcesDecoder. Sorry if there's any formatting issues, I made the changes on my phone.

[iBotPeaches]

At a conference a few days ago and someone mentioned how they'd love to see the resolved references in smali and I forgot about this unmerged PR.

My comments still stand, but I pulled it down and was curious about this. It appears to be using my folder (filename?) for the path. Is that right?

    const v0, 0x7f0805ba    # 3554.drawable.wheel_bg
    const v0, 0x7f0805ba

    .array-data 4
        0x7f0400de    # 3554.attr.circleCrop
        0x7f040231    # 3554.attr.imageAspectRatio
        0x7f040232    # 3554.attr.imageAspectRatioAdjust
    .end array-data

[kosovo0275]

If I remember correctly I set it up to use 2 different references. One for the system resources found in the android.jar, which were all prefaced with #Android..... in the smali files, and one for any local resources that would be found in your app, which I think I decided to just base the reference name on the filename of the apk, since that seemed like the only reliable, universal way to reference the local resources. I thought about parsing the manifest to get/use the package name, but since I was still extremely new to Java at the time, I wasn't exactly sure how to implement it properly. Seemed like a reasonable trade-off

On Wed, Apr 10, 2024, 4:05 AM Connor Tumbleson @.***> wrote:

Screenshot.from.2024-04-10.07-02-04.png (view on web) https://github.com/iBotPeaches/Apktool/assets/611784/890c9c29-fae6-4f27-8d1f-65ee98308b9b

At a conference a few days ago and someone mentioned how they'd love to see the resolved references in smali and I forgot about this unmerged PR.

My comments still stand, but I pulled it down and was curious about this. It appears to be using my folder (filename?) for the path. Is that right?

const v0, 0x7f0805ba    # 3554.drawable.wheel_bg
const v0, 0x7f0805ba

.array-data 4
    0x7f0400de    # 3554.attr.circleCrop
    0x7f040231    # 3554.attr.imageAspectRatio
    0x7f040232    # 3554.attr.imageAspectRatioAdjust
.end array-data

— Reply to this email directly, view it on GitHub https://github.com/iBotPeaches/Apktool/pull/3317#issuecomment-2047240061, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMOTCLIHOCMRCXEVFUGWPLY4UMH7AVCNFSM6AAAAAA4KEFG6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXGI2DAMBWGE . You are receiving this because you authored the thread.Message ID: @.***>

[iBotPeaches]

thanks - so if you patch it with the package name of that resource (pkgId) - it would seem better?

[kosovo0275]

I wouldn't say better, but it would be more uniform and reliably predictable. I personally prefer the filename approach, since I mostly use apktool on my phone in termux, so screen real-estate was the biggest factor for me, and since the whole idea behind why I implemented it was to simplify the analysis of small code, something like

#base.string.app_name

seemed more appropriate than something like

#com.android.example.app.tutorials.string.app_name

On Wed, Apr 10, 2024, 2:33 PM Connor Tumbleson @.***> wrote:

thanks - so if you patch it with the package name of that resource (pkgId)

• it would seem better?

— Reply to this email directly, view it on GitHub https://github.com/iBotPeaches/Apktool/pull/3317#issuecomment-2048472573, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMOTCO53MSEG4BRJWEAOXDY4WV2HAVCNFSM6AAAAAA4KEFG6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBYGQ3TENJXGM . You are receiving this because you authored the thread.Message ID: @.***>

[iBotPeaches]

I see - I guess I'm curious what seems more correct in terms of an engineer - like maybe I'll look at the references in writing directly in Java.