Exetools - URET Android Reverser Toolkit v1.1

Exetools (https://forum.exetools.com/index.php)

- Community Tools (https://forum.exetools.com/forumdisplay.php?f=47)

- - URET Android Reverser Toolkit v1.1 (https://forum.exetools.com/showthread.php?t=17398)

Quote:

Originally Posted by niculaita (Post 111873)

trying to decompile http://www79.zippyshare.com/v/MwEq2Bu3/file.html I got this messages:

14.01.2018 02:55:54
S: WARNING: Could not write to (C:\Users\Niculaita\AppData\Local\apktool\framework), using C:\Users\Niculaita\AppData\Local\Temp\ instead...
S: Please be aware this is a volatile directory and frameworks could go missing, please utilize --frame-path if the default storage directory is unavailable

Done...

try to delete apktool folder ,you can also update apktool to latest just replace it in /Binaries folder

but dont replace smali/baksmali latest version are not supported i will support it in next update just need time

Thank you for your answers,
I"ll narrow down my goal:
input: windows OS, obfuscated dex (with tricky namespace +classes names like A, a, etc)
output: .jar file with java *.class files
I know that jar is zip in nature and it supports A, a in the same folder
but will it be possible to compose such a zip under WIndows OS?

thanks

Quote:

Originally Posted by sendersu (Post 113308)

use Ultra compare by IDM

https://www.ultraedit.com/products/ultracompare/

or zipdiff

http://zipdiff.sourceforge.net/

windows will not support unpacking because same name even case sesntive windows takes it as same file but within zip it may work

Well, thanks
but the question was - are there any tools that could write under Windows a and A into same dir inside zip archive

if yes, then one could explore such a zip later on using say 7zip or winrar, etc
so the main q is how to produce such a zip under Window OS

I think the answer to your question depends on this: what is the source of the files?

Since Windows does not allow dealing with duplicate case-sensitive files, you can't have the source files directly on the filesystem. There are some registry settings and hacks to partially enable that support, but for the NTFS part only and not for Explorer or other windows portions. You'll need to use Cygwin or other Linux compatibility layers (see some info here: hxxps://superuser.com/a/430645 and other answers on the same question).

Now, assuming you'll need to forget about having the expanded files on the disk, what is your scenario?
Do you have a jar with A.class, a.class and need to produce a zip with A.java, a.java? Or a .dex and the need to produce a zip with A.class, a.class? etc.

Note that I'm not saying I'll be able to provide an answer, I'm just stating that you should clarify your actual need :D

Hi Mkz!
thank you for your interest,
its always cool and motivates to move forward in case o flive discussion/arguing

so, in two words, I"m looking for this scenario:
dex (having A, a in one dir) ==> .jar (having A, a in one dir)

of course under Win OS it won't be possible to keep A, a in the same dir, but this is not a must!
unfortunately majority (99%) of the tools are not taking into account this simple fact and are producing crap (again, only under Windows super duper OS)

I see the soluion smth like
tool is reading content of input archive and does NOT write it (or temp or final files) into FS, but keeps it in memory (eg in std::map, dictionary/whatever)
and when the main job is done (deobfuscation or converting dex to jar) then it'll directly write each itme into jar (=zip)

so I"m very wondering whether it is possible under Win OS to write into archive (jar) A, a into same dir...

if some tool will master it -the really huge amount of obfuscators will sux :)
as keeping a/A in same dir is the main stopper for the moment.

Dex2Jar (hxxps://github.com/pxb1988/dex2jar/releases) will do what you want, it writes the converted classes from the source .dex directly into the .jar, bypassing the case insensitivity limitation of the Windows FS.
I just tried it on an apk/dex I had here and the resulting .jar did contain a.class and A.class in the same folder. jd-gui was able to decompile each of them separately.

Note that you can also use Dex2Jar to convert a .jar to .dex, so that you can analyze it under JEB.
One of the best features I like about JEB is the fact that it lets you rename each class/type and variable names to something meaningful as you interpret the logic, and it will replace every reference to it (excepty reflection or string literals, of course). I don't remember any other tool that allows that.
The problem with JEB is that it's rather unstable and some classes or methods make it crash, not all methods can be decompiled, etc. But I guess most Java decompilers have that problem too.

Thanks for details
I get success only doing things on Linux OS
Windows each time break or mis-behave on my A/a dex

what are your steps to reach the success under win OS?

Try this:

1. Grab Dex2Jar from here hxxps://github.com/pxb1988/dex2jar/releases/tag/2.1-nightly-28 and unpack it to a folder
2. Take the sample I attached, some old APK I had lying around with these duplicates
3. Extract the .dex file from within: "unzip *.apk classes.dex"
4. C:\...\...\d2j-dex2jar.bat classes.dex
5. Look at the output jar, it has the duplicates: "jar tf classes-dex2jar.jar | findstr com/a/a/ac/[aA]\.class" - 2 separate files exist for that package, for instance (more exist)

Quote:

Originally Posted by sendersu (Post 113416)

Thanks for details
I get success only doing things on Linux OS
Windows each time break or mis-behave on my A/a dex

what are your steps to reach the success under win OS?

UART has Dex2jar and Jar2Dex feature in it :) you can drag and drop the dex and use the function and you will get output in the working directory:)

@Mkz

thank you for the detailed steps, but there is one generic issue (bug?)
the output jar shows two a.class files in one dir
how it is possible at all?

after some pondering I've found out the reason!
windows os has even worse limitataion
if you have dirs like
a
A

then it shows just one dir, say A
in which it shows files with absolutely same name - a.class and a.class (which must be in diff dirs - A and a)

I'm still wondering if thats a Windoze limitation or a d2j bug
Under LInux stuff is ideal - http://prntscr.com/jli383

Ah, I see your point now. The duplication a/A was not on the filenames, but on the folders / package names.

After a lot of confusion, because I was having the same problem you mentioned, I think I figured out the reason. It was 7-zip's problem, not the generated JAR :mad:

Here's some standalone java code to create a JAR with duplicate directories (and files as well):

Code:

import java.io.File;

import java.io.IOException;

import java.nio.file.FileSystem;

import java.nio.file.Files;

import java.nio.file.Path;

import java.nio.file.spi.FileSystemProvider;

import java.util.HashMap;

import java.util.Map;





/**

 * Test code for Zip creation from within java

 * 

 * Extracted from Dex2Jar code, more specifically:

 *   https://github.com/pxb1988/dex2jar/blob/eca2c98278ec30e31c3953e0a030505987a6f8ca/dex-translator/src/main/java/com/googlecode/d2j/dex/Dex2jar.java#L270

 *

 */

public class ZipFSTest {



    public static void to(Path file) throws IOException {

        if (Files.exists(file) && Files.isDirectory(file)) {

            doTranslate(file);

        } else {

            try (FileSystem fs = createZip(file)) {

                doTranslate(fs.getPath("/"));

            }

        }

    }



    private static void doTranslate(Path file) throws IOException {

        byte[] contents = new byte[] { 0x40, 0x41, 0x42 };

        

        System.out.println("Translating path: " + file);

        

        System.out.println("Creating: " + file.resolve("/a/b/c/").toAbsolutePath());

        Files.createDirectories(file.resolve("/a/b/c/"));

        Files.write(file.resolve("/a/b/c/a.txt"), contents);

        Files.write(file.resolve("/a/b/c/A.txt"), contents);

        

        System.out.println("Creating: " + file.resolve("/A/b/c/").toAbsolutePath());

        Files.createDirectories(file.resolve("/A/b/c/"));

        Files.write(file.resolve("/A/b/c/a.txt"), contents);

        Files.write(file.resolve("/A/b/c/A.txt"), contents);

        

        System.out.println("Creating: " + file.resolve("/a/b/C/").toAbsolutePath());

        Files.createDirectories(file.resolve("/a/b/C/"));

        Files.write(file.resolve("/a/b/C/a.txt"), contents);

        Files.write(file.resolve("/a/b/C/A.txt"), contents);

    }



    private static FileSystem createZip(Path output) throws IOException {

        Map<String, Object> env = new HashMap<>();

        env.put("create", "true");

        Files.deleteIfExists(output);

        Path parent = output.getParent();

        if (parent != null && !Files.exists(parent)) {

            Files.createDirectories(parent);

        }

        for (FileSystemProvider p : FileSystemProvider.installedProviders()) {

            System.out.println("Checking provider: " + p.getClass().getName());

            String s = p.getScheme();

            if ("jar".equals(s) || "zip".equalsIgnoreCase(s)) {

                return p.newFileSystem(output, env);

            }

        }

        throw new IOException("cant find zipfs support");

    }

    

    public static void main(String[] args) throws IOException {

        

        to(new File("abc.zip").toPath());

        System.out.println("Done");

    }



}

If you run it on windows, you'll end up with "abc.zip" like the one I attached here.
Open it on 7-zip and you'll see a single root dir "a", followed by "b" and finally by "c". Inside there are 3 "a.txt"'s and 3 "A.txt"'s - the problem you mention.

However, list the file contents from the command line and all is well:
"jar tf abc.zip" or "unzip -l abc.zip":

Code:

a/

a/b/

a/b/c/

a/b/c/a.txt

a/b/c/A.txt

A/

A/b/

A/b/c/

A/b/c/a.txt

A/b/c/A.txt

a/b/C/

a/b/C/a.txt

a/b/C/A.txt

Open it in jd-gui and each package is separated, with A.txt and a.txt inside :)

Just wish I had not wasted so much time blindly trusting 7-zip's output and digging through the JRE's com.sun.nio.zipfs.ZipFileSystemProvider until remembering to use a command line listing of the archive contents. :o

there are many links in this thread, which one you are looking for?