maven releases

[AriaMoradi]

Hey, currently I'm using @Lanchon version of dex2jar https://github.com/DexPatcher/dex2jar/releases/tag/v2.1-20190905-lanchon using jitpack (https://jitpack.io/#DexPatcher/dex2jar)

I wonder if you are planing to release your changes to any maven repo?

Also does your fork also have the same patches? (mainly speaking I use Dex2jar from dex-tools which converts apk files to jar files, and it supports up to dex version 038)

[ThexXTURBOXx]

Hey, Lanchon didn't add any patches to dex2jar as far as I know. He just compiled the most recent state of the master branch, which fixed many bugs since 2.0. Since my patches are based on the same branch, I actually do include everything that DexPatcher has (and much more!) :D

I patched many bugs, which you can read in the commits about. BytecodeViewer uses the latest version if you want test my version of dex2jar in a GUI first.

I do plan to release it to some kind of maven repo (either central or my own), but I will ask @pxb1988 first if I may do that.

[Lanchon]

hi,

Lanchon didn't add any patches to dex2jar as far as I know

i did, it's here: https://github.com/DexPatcher/dex2jar/releases/

using jitpack

yuck! dxp has had a repo for ages now: https://dexpatcher.github.io/dexpatcher-repo/

[Lanchon]

I will ask @pxb1988

good luck with that :-p

[Lanchon]

I do plan to release it to some kind of maven repo (either central or my own)

maybe take a look at dexpatcher-repo-updater.

[ThexXTURBOXx]

i did, it's here:

Did you change the source code, though? As far as I can see, the newest release states "This is the current state of official pxb1988/dex2jar".

good luck with that :-p

Thanks, Yea, I guess, he won't reply here, but it's still worth a try. Apache License doesn't forbid me to distribute it, so I guess, I might be uploading it somewhere soon

maybe take a look at dexpatcher-repo-updater

I will do that, but might stay with Github actions still. But thank you :)

[ThexXTURBOXx]

@Lanchon I just double-checked your commits and it looks like they are included in the official repo since your bug reports. So, @AriaMoradi yes, DexPatcher's patches are also somehow included here :)

I will keep this issue open as a reminder for me to set up the Maven repo, though

[AriaMoradi]

I tried using your fork through jitpack, assuming implementation("com.github.DexPatcher.dex2jar:dex-tools:v2.1-20190905-lanchon") works for me, I tried replacing it with implementation("com.github.ThexXTURBOXx:dex-tools:v19"), but looks like the maven-publish tasks are broken? Jitpack failed to build it.

relevant links:

• https://jitpack.io/#ThexXTURBOXx/dex2jar/v19
• build log from jitpack: https://jitpack.io/com/github/ThexXTURBOXx/dex2jar/19/build.log

[Lanchon]

@Lanchon I just double-checked your commits and it looks like they are included in the official repo since your bug reports.

yes, bob later fixed the bugs independently and differently. i assume his fixes are just fine.

Yea, I guess, he won't reply here, but it's still worth a try. Apache License doesn't forbid me to distribute it, so I guess, I might be uploading it somewhere soon

dex2jar has been abandonware for quite a while now. and frankly the code seems to be a quick hack rather than having a focus on quality. i once thought of keep it going forward but the thing is just too messy. this is really sad because we have no alternatives.

so if you are maintaining it, by all means, start publishing builds.

IMHO the only real solution is an alternative implementation, and i can give you some pointers if you feel inclined to try your hand at it.

I tried using your fork through jitpack,

jitpack is a pile of crap. the package naming they used clashes with everything, and they give no control to software authors they clash with. i'd advice you not to use it.

maybe take a look at dexpatcher-repo-updater

I will do that, but might stay with Github actions still

yeah, this updater predates github publishing, which is probably better for you (the updater does not publish source packages). i needed to publish stuff others didn't care to, so i had to find a way. but i don't pollute the namespaces bc my published stuff is prefixed with dexpatcher-repo..

[ThexXTURBOXx]

I tried using your fork through jitpack

As @Lanchon said, jitpack isn't really the greatest thing. Especially because of sub-modules not working correctly in many cases. I might disable jitpack via a intentionally failing .jitpack.yml such that people don't do bad things.

Yes, Bob later fixed the bugs independently and differently

Okay, very good to hear, thank you :)

This is really sad because we have no alternatives

That's true to a small extent. JADX is also working pretty good, actually. But yeah, dex2jar is normally the place to go to.

Start publishing builds

That's true. It is, in fact, abandoned. Maybe I will also just upload the builds to my github io page (which was actually a very good idea from you!).

I might give you some pointers

As soon as I need some help, I might come back to that offer. Thank you very much :)

[Lanchon]

JADX is also working pretty good, actually

but a bytecode decompiler to java will always fail by definition: many bytecode constructs do not have a java language equivalent. dexing however is "effectively" reversible. by this i mean generating java bytecode that behaves the same under all conditions. or you could define it as java bytecode that can be dexed back into dex bytecode that behaves the same as the original under all conditions.

most tools work with java bytecode. even the modern android build system does not understand dex except for the final (incremental) dexing step. so being able to reverse dex is really important to harness all the bytecode tools of the java ecosystem. comparatively, dex has almost no tools. and it doesn't make sense to create them: a single robust dedexer is what is needed.

on the topic of decompilers: until someone defines an extended java-like language, there will be no correct java decompiling. this language needs identifier quoting, full name clash support, some sort of goto construct, etc. the idea is guaranteed correct round trips, even if decompiling code from obfuscators looks, well, obfuscated. i tried to sell this idea to the best man for the job, the author of CFR, but he didn't like it.

As soon as I need some help, I might come back to that offer

it is not help, just some ideas. i'll push them here against your will anyway :)

CFR includes it's own class file reader (hence the name). big no, if someone will work on a dex2jar successor, it should be based on well known and supported existing packages. the java bytecode side is a no-brainer: ASM. the dex side is not so clear cut.

the obvious candidate is dexlib2, part of smali, maintained by JF. but it has some drawbacks: dexlib2 has been many times on the brink of being abandoned, with JF falling behind android releases by several majors. so far, one day he comes out of the blue and resumes, but you never know if that is going to be the case next. also, sporadic development means he forgets some aspects of the codebase and makes mistakes when extending it. example: there are several "things" to be handled in many places, and if a new thing is later added, the compilation will not fail if a new handler is not added somewhere; it is just a characteristic of the codebase. also dexlib2 is slow as hell. not a big deal, but robust tools need to be quick to allow interactive reversing.

a little known thing about dexlib2 is: google likes having two completely independent dex i/o codebases to make it possible to catch implementation errors in either. and yes, the android build system builder tests the main code with dexlib2. the android tool guys get anxious when JF falls behind, so they maintain a fork of smali: it is inconspicuously sitting on a corner in the android tools repo. so even if dexlib2 goes dead, that fork might be kept alive anyway.

but there is an alternative: d8/r8, the standard android dexers, maintain their own dex bytecode i/o routines. they are maintained by the guy who developed the first javascript JIT compiling runtime: v8 (the 8 in d8/r8 are references to v8). d8/r8 are extremely fast (its main reason for existence) and will be kept up to date... until maybe the winds change and they are dropped, like 'dx' once was.

if i were you, i would lean towards d8/r8. once you are up to speed whatever libs you use to read/write all bytecode, translation itself shouldn't be too difficult. code you can base on is available in the form of enjarify, both in its original form and in its RUST rewrite. enjarify is quality code. unfortunately it is abandonware. also, it rolls its own bytecode i/o meaning maintaining it is a pain. also, it is not compilable to java bytecode, and we really need java/dex bytecode reversing tools that can be hosted in a JVM.

[ThexXTURBOXx]

@AriaMoradi v20 is now available as version from jitpack.io I might set up my own maven repo at some point, but for now, jitpack works good enough :P

@Lanchon Thank you very much. I actually already included d8/r8 in dex2jar, but it doesn't use it yet. I will enable it at some point in the near future. For now, I will close this issue as the Maven repo is "set up" and at some point, I (or maybe even someone else) will come back to your comments again. Thank you very much for your sharing of ideas, I really appreciate it :)

[ThexXTURBOXx]

@AriaMoradi Small update: v21 now also includes DX and D8/R8. I forgot to include them before :)

[AriaMoradi]

My code is using org.ow2.asm for bytecode editing, previously it was version locked by dex2jar to version 5.0.3 now you have updated to 9.2, some parts of the code expose it with api and others don't and just use implementation.

1- What's your plan with this package? Any planed updates soon? or deprecation? 2- Are you going to expose it with api externally or not?

[ThexXTURBOXx]

now you have updated to 9.2

That was actually one of my first changes to Dex2Jar as most applications want the newest version of all libraries and I needed to make Dex2Jar compatible with those.

What's your plan with this package? Any planed updates soon? or deprecation?

I am not sure exactly. The main reason why I forked Dex2Jar in the first place is that BytecodeViewer had many bug reports regarding Dex2Jar. So, I fixed those. If there are additional bug reports, I will try to fix those as well, of course. Feature enhancements are not yet planned. I will take a look at those once most bugs are out of the way (there are most likely still plenty!)

Are you going to expose it with api externally or not?

I don't have much experience with Gradle, I just don't like the unnecessary complexity in contrast to e.g. Maven (e.g. this line was driving me crazy). I was unsure which one of those to use, so I just stuck with those that worked. If there are any optimizations to the Gradle files, I am very much open for any PRs from experts in the field :)

[AriaMoradi]

        val dex2jarVersion = "v21"
        implementation("com.github.ThexXTURBOXx.dex2jar:dex-translator:$dex2jarVersion")
        implementation("com.github.ThexXTURBOXx.dex2jar:dex-tools:$dex2jarVersion")

the above worked, I needed to include dex-translator for access to BaksmaliBaseDexExceptionHandler

Also this is my converter code if anyone needs it

    /**
     * Convert dex to jar, a wrapper for the dex2jar library
     */
    fun dex2jar(dexFile: String, jarFile: String, fileNameWithoutType: String) {
        // adopted from com.googlecode.dex2jar.tools.Dex2jarCmd.doCommandLine
        // source at: https://github.com/DexPatcher/dex2jar/tree/v2.1-20190905-lanchon/dex-tools/src/main/java/com/googlecode/dex2jar/tools/Dex2jarCmd.java

        val jarFilePath = File(jarFile).toPath()
        val reader = MultiDexFileReader.open(Files.readAllBytes(File(dexFile).toPath()))
        val handler = BaksmaliBaseDexExceptionHandler()
        Dex2jar
            .from(reader)
            .withExceptionHandler(handler)
            .reUseReg(false)
            .topoLogicalSort()
            .skipDebug(true)
            .optimizeSynchronized(false)
            .printIR(false)
            .noCode(false)
            .skipExceptions(false)
            .to(jarFilePath)
        if (handler.hasException()) {
            val errorFile: Path = File(applicationDirs.extensionsRoot).toPath().resolve("$fileNameWithoutType-error.txt")
            logger.error(
                """
                Detail Error Information in File $errorFile
                Please report this file to one of following link if possible (any one).
                https://sourceforge.net/p/dex2jar/tickets/
                https://bitbucket.org/pxb1988/dex2jar/issues
                https://github.com/pxb1988/dex2jar/issues
                dex2jar@googlegroups.com
                """.trimIndent()
            )
            handler.dump(errorFile, emptyArray<String>())
        } else {
            BytecodeEditor.fixAndroidClasses(jarFilePath.toFile())
        }
    }

[ThexXTURBOXx]

the above worked, I needed to include dex-translator for access to BaksmaliBaseDexExceptionHandler

You should be able to just import dex2jar itself:

implementation("com.github.ThexXTURBOXx:dex2jar:v21")

Also this is my converter code if anyone needs it

I think, it would be best to change the links or email to my information as @pxb1988 won't be able to do much about these issues, like this :)

[Lanchon]

@ThexXTURBOXx

I actually already included d8/r8 in dex2jar, but it doesn't use it yet.

i think you misunderstood me. what i meant is: a replacement for dex2jar needs to read/write bytecode, both java and dalvik. for java bc I/O you'd use ASM. now what to use for dex? i propose using the i/o implementation within d8/r8. now that the idea is clear, please reread my long message for more info.