jadx | Dex to Java decompiler | Bytecode library

I am decompiling java application, and i have already done with 99% .class files. But, I have a problem with couple of them: error while decompilation (errors are same type). Example:

Procyon: java.lang.IllegalArgumentException: Argument 'index' must be in the range [0, 63], but value was: 15873...

CFR:

I would like to add something to an app, so I added some lines to a smali file (decompiled the apk using apktools) and then repackaged and ran it on a real device. It shows

• 10121 10211 E AndroidRuntime: os.json.JSONObject a.b.a.a.a.i.m(android.context.Context, java.lang.String) Failed to verify: os.json.JSONObject a.b.a.a.a.i.m(android.context.Context, java.lang.String): [0x161] v0 has type Conflict but expected Reference: java.lang.AutoCloseable (declaration of 'a.b.a.a.a.i' in /data/app/xxxx/xxxxx/base.apk)

So what does the [0x161] refer to? Is it a line number? 0x161 = 353 in decimal. So I checked the smali code, but the function a.b.a.a.a.i.m has less than 353 lines in smali, so there is no line 353 and I can not locate the error.

Neither does this function have enough lines in java (I used jadx to decompiled the generated apk).

So in which type of file can I locate the problem in file's line 353? Should I transformed the apk into some other format to find a line 353 to troubleshoot the error? Thanks in advance.

I have several dex files that needs to be statically analyzed by mobsf after unpacking the apk file because core code are inaccessible prior to unpacking.

What I've tried: Adding Line 3 and changing line 4 from glob_pattern = app_dir + *.dex' to glob_pattern = ddex_dir

I have decompiled an application using APKTool and JadX and I'm trying to manually restore a few spots that didn't decompile correctly. So far it's going slow but steady and I've fixed all of the other ones. But I'm a bit stumped by the following line:

I want to be able to parse APK files from various sources, or various kinds. I want to get only very specific, basic information about them:

• package-name
• version-code
• version-name
• label (app name)
• icon
• minSdkVersion
• whether it's a split APK or not (available when parsing the manifest)

The Android framework has a single function to parse APK files (PackageManager.getPackageArchiveInfo), but it has 2 disadvantages:

1. It requires a file-path. This isn't always available, as you might have a Uri to deal with, or you have the APK file being inside some ZIP file.

2. It can't handle split APK files. Only the base one of them. If you try it on split APK files, you just get null.

Because of this, I've tried to find a reliable, Java&Kotlin solution that can handle them easily.

Each solution I've found has its own disadvatanges. Some libraries I couldn't even find how to use, and some don't have any way to parse APK files without having a real file path. Some of them just create new files instead of returning you objects in Java/Kotlin. Some are even in other programming languages, making me wonder if it's possible to use them.

So far, the only one that I've found as good enough, is "hsiafan" apk-parser, which needs only 2 files within the APK: manifest and resources files. It has some issues, but usually it can get you the information I've mentioned.

Thing is, as I wrote, it's not always working, so I want to return to the basics, at least when I notice it fails to parse, at least for the case that it's a normal APK of base of split-APK files. Some cases it couldn't handle well are:

1. Sometimes the app name couldn't be fetched correctly (here).
2. Some resources are somehow hidden in some apps (here). Even tools such as Jadx fail to show them, but others can.
3. Adaptive icon is hard to parse, including drawable XML files. I succeed parsing VectorDrawable though (here), but it's quite a workaround.

And a few others.

So, I wanted to try out the Android framework again, but this time with a new idea: instead of handling the entire original APK, I could extract only what it really needs, based on the current observation of it.

For example, if I know the resources I need to handle, I can copy only them (and some key files that are needed) into a new APK, and ditch the rest. This could reduce the need to copy/download huge amount of data just to parse the APK and get information about it. If the APK file is 100MB, for example, there is no need to get it all when all we need is just a tiny portion of it.

As a start, I wanted to see how I can create a new APK that can be parsed, so for now I copied all of the entries of the original APK (currently of the current app) into a new file, and chose to parse it:

I'm a begginner in android pentest and I'm using some decompiler like jadx but sometimes It does'nt work on decompiling some classes,

but when I drag and drop the .class file in android studio it decompiles it.

So is there a tool that use the android decompiler to decompile android application ? Or is there any way to decompile a complete APK without drag & droping each class files to android studio ?

Thank you

I ran an APK through dex2jar and JD-GUI and found the class I'm interested in: