UPDATE: version 1.0.0-beta2 released!
Changelog in the previous link. Do you use DexPatcher? Say hi on this thread!
Changelog in the previous link. Do you use DexPatcher? Say hi on this thread!
[TOOL] DexPatcher: Modify Android applications at source-level in Android Studio
- Thread starter Lanchon
- Start date
Hi !
I read a few about the tool and plan to try as soon as I have few time (I'm moving my home this month…).
I keep thinking this tool is really useful when you have a lot to patch in smali.. (which is a real pain comparing to java coding).
I also plan to port the scripts to windows (as the tool is cross platform).
Note: Any clue about DexPatcher usage with GitHub traffic analytics?
Hi !
I read a few about the tool and plan to try as soon as I have few time (I'm moving my home this month…).
I keep thinking this tool is really useful when you have a lot to patch in smali.. (which is a real pain comparing to java coding).
I also plan to port the scripts to windows (as the tool is cross platform).
Note: Any clue about DexPatcher usage with GitHub traffic analytics?
well 5 people forked it but no commits so far.
great, i can help u with the windows scripts if u want. im sure itd help people get started. you might want to look at these kinds of expasions: https://code.google.com/p/dex2jar/s.../src/main/bin_gen/d2j_invoke.bat?name=0.0.9.x
May be you could see with @Diamondback to get integration of your tool in a more known one like VTS?
And more userfrendly than a CLI! No offense, I'm fine with CLI but GUI often get more users…
lol yes, and so does windows
but im not in the business of pushing tools! i dont plan to do that because ive got more interesting things to do if i have the time IMHO. btw, i think eclipse integration is much more valuable than any adhoc gui. im using dexpatcher with eclipse (jdt) and its great. eclipse really helps with both analyzing the source app and writing the patch. i should do a write up on how to set it up. (it does need the scripts to set up things though.)much better than win scripts would be an eclipse extension. i just dont have time to write that.
Better than the script to set up, you could have a "DexPatcher project" type in Eclipselol yes, and so does windows
much better than win scripts would be an eclipse extension. i just dont have time to write that.
Otherwise, IDEA plugin could also be an "idea". I wonder how many devs have switch to IDEA since the devtools are officially base on Intellij software…
Better than the script to set up, you could have a "DexPatcher project" type in Eclipse
Otherwise, IDEA plugin could also be an "idea". I wonder how many devs have switch to IDEA since the devtools are officially base on Intellij software…
but im using JDT in eclipse, not ADT.
UPDATE: version 1.0.0-beta3 released!
Changelog in the previous link. This is a major update and feels feature complete, but I still need to accrue more experience in using it before a release. The sample in the OP has been updated to match and uses the latest features. Be sure to check it out if you haven't in a while, you can use the commit history to find the recent changes.
I've also published a supplemental tool called ExtractAR; can you guess what i'am after next?
As a side note, I've been using DexPatcher in a couple of real world projects and, after setting up symbols and scripts in Eclipse, i'm really pleased with the development experience and speed... not to blow my own horn. it used to be 20% of the time to figure out what to change and 80% to actually do it. now 90% of the time is figuring out what i want to do and only 10% doing it, and i'm doing complex changes i wouldn't have dared to before!
Changelog in the previous link. This is a major update and feels feature complete, but I still need to accrue more experience in using it before a release. The sample in the OP has been updated to match and uses the latest features. Be sure to check it out if you haven't in a while, you can use the commit history to find the recent changes.
I've also published a supplemental tool called ExtractAR; can you guess what i'am after next?
As a side note, I've been using DexPatcher in a couple of real world projects and, after setting up symbols and scripts in Eclipse, i'm really pleased with the development experience and speed... not to blow my own horn
. it used to be 20% of the time to figure out what to change and 80% to actually do it. now 90% of the time is figuring out what i want to do and only 10% doing it, and i'm doing complex changes i wouldn't have dared to before!
Hi @Lanchon
Any news about a final release? Did you think about some improvement or new feature to add it?
Not for asking ETA, just to wake up some interest about the project
Hi @Lanchon
Any news about a final release? Did you think about some improvement or new feature to add it?
Not for asking ETA, just to wake up some interest about the project
ive been working *a lot* on this! although it doesnt show
so for DexPatcher...the current version should be considered v1 feature complete. it is mostly there. there will be a new release that integrates dexlib 2.0.6 over current 2.0.5, which includes some api changes that i requested for dexlib that increase polymorphism and cleans the DexPatcher codebase all around. but there should be no user-facing changes, this is implementation detail. a final release is only pending testing, that's what the beta is for!
unfortunately i haven't tested dexpatcher as extensively as i would have wanted: instead of using dexpatcher, ive been busy crash-coursing on groovy, gradle, the android build system, and android studio itself. im working on deep integration of dexpatcher into the new android build system. had i knew the amount of work this would take first hand, i wouldnt have embarked on it! seriously! integration will finally take 5 to 10 times more work than the tool itself. but the good news is that a preview release is relatively near. and it will be... awesome! the scope far exceeds the dexptacher tool, but for now ill only say that i've embraced the sad fact that not everybody uses linux, and dexpatcher reloaded is completely multiplatform
the only real problem i have is an impending set of trips, to the US and europe, and if i dont finish the tooling in time and publish, i will completely forget all the complexity im dealing with now in my head. and when im back months later, i suspect i wont have inclination to continue. yes im learning *a lot*, thats true, but most of the stuff im doing is really *not* enjoyable.
regarding the future of the dexpatcher tool, the big missing piece of the puzzle is multidex support. it was consciously left out because 1) *i* dont need it for my projects, and 2) you have to control feature creep and release early! i don't know enough about multidex to even begin to tackle the problem in my head. multidex is a horrible hack. i suppose dexptacher will gain multidex support, but suspect that it will only support multidex enabled dalvik VMs, and not the old VMs on which multidex runs thanks to libraries packaged with each apk.
tl;dr trust me, you'll love the new dexpatcher
hopefully it'll trigger wide acceptance of the tool. but for now it's nice to see some interest, so thanks for stopping by!
You're welcome and thanks for your hard work!tl;dr trust me, you'll love the new dexpatcher
Keep learning and improving stuff. You will learn to enjoy it even if it's not fun at all
You're welcome and thanks for your hard work!
Keep learning and improving stuff. You will learn to enjoy it even if it's not fun at all
luck you, you didn't have to wait that long
after a lot of work i just finished what appears to be a fully working 0.1 release, phewww!!! there's still packing and publishing work pending, things that i know nothing about. and the damn docs!! i don't know if i will have time to publish before my trips, but the good news is that its finished so it will be published sooner or later
THE ALL-NEW DEXPATCHER PREVIEW IS UP !!!
Come take a look !
Come take a look !
Last edited:
Integration to Android Studio! Nice!THE ALL-NEW DEXPATCHER PREVIEW IS UP !!!
Come take a look !
Testing it goes straight to my todo list
I need some help or directions about what to do :crying: I have been trying this tool to patch an APK file and its keep crashing. Probably not related to this tool but a help or direction would be appreciated.
I created a patch and successfully compiled and it was crashing at start. Then I removed the patched java file and recompiled it without any patches and It was still crashing. Checked the catlogs and I see exception is being thrown from some sqlite encryption adapter complaining about file is encrypted. App is also using AESObfuscator (might be related). So what I think is; after it gets repacked into a new apk something about encrypted sqlite file gets broken because of this AESObfuscator? If so should I remove this and how can I remove this? A link to a tutorial or something will be helpful. Would it be better to use something like Xposed in this situation? Thanks.
I created a patch and successfully compiled and it was crashing at start. Then I removed the patched java file and recompiled it without any patches and It was still crashing. Checked the catlogs and I see exception is being thrown from some sqlite encryption adapter complaining about file is encrypted. App is also using AESObfuscator (might be related). So what I think is; after it gets repacked into a new apk something about encrypted sqlite file gets broken because of this AESObfuscator? If so should I remove this and how can I remove this? A link to a tutorial or something will be helpful. Would it be better to use something like Xposed in this situation? Thanks.
I need some help or directions about what to do :crying: I have been trying this tool to patch an APK file and its keep crashing. Probably not related to this tool but a help or direction would be appreciated.
I created a patch and successfully compiled and it was crashing at start. Then I removed the patched java file and recompiled it without any patches and It was still crashing. Checked the catlogs and I see exception is being thrown from some sqlite encryption adapter complaining about file is encrypted. App is also using AESObfuscator (might be related). So what I think is; after it gets repacked into a new apk something about encrypted sqlite file gets broken because of this AESObfuscator? If so should I remove this and how can I remove this? A link to a tutorial or something will be helpful. Would it be better to use something like Xposed in this situation? Thanks.
by design, this tool creates a new apk, which means that the signature needs to change. some apps or libraries of those apps check their own signature and fail to run if something is unexpected. for example, the google map library requires a key for each app. if you resign the app the library will stop working, unless you get a new key for your signature.
for debugging non-working apps:
1) resign the app without any modifications. if there is a problem, it's the signature.
2) use apktool to decode and rebuild the app without mods. if there is a problem, it's an apktool bug (or misconfiguration; read the section on frameworks on the apktool docs).
3) now you know it's a problem with your patch or the DexPatcher toolchain.
for signature problems:
unless you want to patch the app to not check, then you need the system to report a fake signature to the app. this can potentially be done this way, though i haven't tested:
1) copy the signature files from the original apk to the modded one. (maybe one day there will be a toolchain extension for this.) now you have an app with an INVALID signature and won't install.
2) modify your system to accept invalid signatures. BUT... beware of the dangers of this!
you can probably do item 2) with the 'XInstaller' xposed module. check the help: http://pyler.wen.ru/XInstaller/Help.html
note that this is probably NOT what you are looking for:
Checking signatures: Disables signatures checking during installations so you can install app over same app even if the signatures don't match.
that probably means that the system continues to verify the validity of signatures, but does not block an app upgrade if the signature changes.instead this is what you are looking for:
Verifying signatures: Disables signatures verifying. Experimental feature (may or may not work on some device, can cause bugs), requires enabled Expert mode.
ENABLE VERIFICATION RIGHT AFTER YOU INSTALL THE PATCHED APP!!!
so to move on, resign the app without any modifications and test this. please report back!
Thanks for detailed explanation. I tried resigning APK without changing anything and yeah it crashed. So it is definitely a problem with sign.
I tried copying signatures from original APK to new APK and installer just crashes with this new APK. Tried with both aligned and unaligned zip files. Tried with disabled XInstaller and it still crashed.
I dug into code of the app, searched for keyword "signature" and found out it is generating some kind of string key from signature to use it on encrypting the sqlite file which is what I already thought. I think I can use Xposed to return that string and after that I can patch that function with DexPatcher to return this acquired string all the time. I am going to try this now.
Also XInstaller idea was good but it defeats the purpose about ability of using the apk on non-rooted devices.
1.0.0-beta4 is out, no biggy, no user facing changes. this will probably end up being the release unless bugs are found.
Similar threads
Top Liked Posts
-
1
thank you very much for the info!
wow... it took them what, 7 years?? rofl!
android is designed to restrict the freedom of users to replace parts of the (typically proprietary) software users need to run. this was done by google to force their proprietary spyware on our phones.
marvin, the author of microg and of the sigspoof mechanism, ran against this very problem. he is a strong software freedom supporter, and thus he designed a free and open solution to these coercive mechanisms. and he named his solution "signature spoofing".
my app correctly flags lineageos as NOT supporting signature spoofing because lineageos DOES NOT support signature spoofing.
lineageos implemented their own custom restrictive solution that only works for builds of a free software project -microg- made by a particular individual, which is ridiculous. this is exactly as restrictive as the google services mircrog is designed to replace.
it is very important that people know that lineageos DOES NOT support sigspoof. because the crap that they did HURTS microg.
picture this: people might be under the false impression that lineageos supports signature spoofing, and so install it and use it with microg. after a long while, google makes a change that breaks microg. or a user needs a certain feature not yet implemented by microg. whatever the case, a user decides to fix or improve microg. he start working on it, debugs the issue, finds out whats wrong, codes a solution, builds it, but... his code somehow doesn't work! and suddenly he realizes that there is no way for him to contribute to the microg project because he can't test his changes because the sutpid lineageos build he runs doesn't support sigspoof! and it is too late to fix lineageos because it is also signed code, and realizes that in order to work on microg he has to wipe his damn phone and start over! this small private debacle will likely end in microg loosing eventual contributors and contributions. all because the lineageos team can't see past their noses.
lineageos DOES NOT support sigspoof, and if they say they do, they are lying: sigspoof is an open mechansim by which the owner of the device, not some marvin@microg, can choose to spoof/alter certain pieces of code carrying anti-features to neuter them.
this whole spoofsig matter is completely out of scope for this dexpatcher thread. but i chose to answer anyway because it tangentially touches what dexpatcher does. dexpatcher allows people to modify evil but necessary proprietary code to make it less evil. for example, imagine you use a dating app that deletes your messages after a couple of days. well it doesn't really deletes them, it holds them ramson: they are there but you can't see them... unless you pay. for your messages! and for messages people sent to you! (yes, this dating app exists and is widely used.) so you can use dexpatcher to disable this anti-feature and access *your* data (which in europe you could force the company to reveal anyway) by modfing the code of the app. but then, the app asks android for its own signature... and sees it is not as expected, and trigger countermeasures! (banning you? wiping your data?) sigspoof comes to the rescue: you modify the app, sign it with your signature, but ask sigspoof to present the original scammer company cert if anybody asks (including itself)... and then the scammers are happily screwed.
sigspoof is an important mechanism for freedom in android. it enables much more than using a microg build that some sacred anoited guy prepared... starting with the chance to help said anoited guy (marvin, who is the real hero of this story).
so armed with this knowledge, please do the right thing and document in the lineageos wiki its reality: that it does not support sigspoof. and though it has a loophole for running official microg without having sigspoof, it does not allow developing microg or any other software that requires sigspoof. users of microg are better served by using a different OS with sigspoof, even if they are not developers, as that would allow them to run unofficial builds of microg that might contain early fixes for issues they are having. or allow them to switch to a microg fork in case official ever becomes dormant.1
Thank you. I really thought I'm an expert in microG related topics. Doday I've learned a lot.
MicroG still works well as user app. It just no longer registers as system location provider. That's why a zoo of microg bundle installers has been made. Modern proprietary apps fetch location directly from play services. That's the point where i see a renaissance of microG user app. An anwer to people that fall for the "sandboxed play services" hype of grapheneOS. -
1
thank you very much for the info!
wow... it took them what, 7 years?? rofl!
android is designed to restrict the freedom of users to replace parts of the (typically proprietary) software users need to run. this was done by google to force their proprietary spyware on our phones.
marvin, the author of microg and of the sigspoof mechanism, ran against this very problem. he is a strong software freedom supporter, and thus he designed a free and open solution to these coercive mechanisms. and he named his solution "signature spoofing".
my app correctly flags lineageos as NOT supporting signature spoofing because lineageos DOES NOT support signature spoofing.
lineageos implemented their own custom restrictive solution that only works for builds of a free software project -microg- made by a particular individual, which is ridiculous. this is exactly as restrictive as the google services mircrog is designed to replace.
it is very important that people know that lineageos DOES NOT support sigspoof. because the crap that they did HURTS microg.
picture this: people might be under the false impression that lineageos supports signature spoofing, and so install it and use it with microg. after a long while, google makes a change that breaks microg. or a user needs a certain feature not yet implemented by microg. whatever the case, a user decides to fix or improve microg. he start working on it, debugs the issue, finds out whats wrong, codes a solution, builds it, but... his code somehow doesn't work! and suddenly he realizes that there is no way for him to contribute to the microg project because he can't test his changes because the sutpid lineageos build he runs doesn't support sigspoof! and it is too late to fix lineageos because it is also signed code, and realizes that in order to work on microg he has to wipe his damn phone and start over! this small private debacle will likely end in microg loosing eventual contributors and contributions. all because the lineageos team can't see past their noses.
lineageos DOES NOT support sigspoof, and if they say they do, they are lying: sigspoof is an open mechansim by which the owner of the device, not some marvin@microg, can choose to spoof/alter certain pieces of code carrying anti-features to neuter them.
this whole spoofsig matter is completely out of scope for this dexpatcher thread. but i chose to answer anyway because it tangentially touches what dexpatcher does. dexpatcher allows people to modify evil but necessary proprietary code to make it less evil. for example, imagine you use a dating app that deletes your messages after a couple of days. well it doesn't really deletes them, it holds them ramson: they are there but you can't see them... unless you pay. for your messages! and for messages people sent to you! (yes, this dating app exists and is widely used.) so you can use dexpatcher to disable this anti-feature and access *your* data (which in europe you could force the company to reveal anyway) by modfing the code of the app. but then, the app asks android for its own signature... and sees it is not as expected, and trigger countermeasures! (banning you? wiping your data?) sigspoof comes to the rescue: you modify the app, sign it with your signature, but ask sigspoof to present the original scammer company cert if anybody asks (including itself)... and then the scammers are happily screwed.
sigspoof is an important mechanism for freedom in android. it enables much more than using a microg build that some sacred anoited guy prepared... starting with the chance to help said anoited guy (marvin, who is the real hero of this story).
so armed with this knowledge, please do the right thing and document in the lineageos wiki its reality: that it does not support sigspoof. and though it has a loophole for running official microg without having sigspoof, it does not allow developing microg or any other software that requires sigspoof. users of microg are better served by using a different OS with sigspoof, even if they are not developers, as that would allow them to run unofficial builds of microg that might contain early fixes for issues they are having. or allow them to switch to a microg fork in case official ever becomes dormant.1
Thank you. I really thought I'm an expert in microG related topics. Doday I've learned a lot.
MicroG still works well as user app. It just no longer registers as system location provider. That's why a zoo of microg bundle installers has been made. Modern proprietary apps fetch location directly from play services. That's the point where i see a renaissance of microG user app. An anwer to people that fall for the "sandboxed play services" hype of grapheneOS. -
58DexPatcher
A toolchain for modifying Android APK files at source-level using Java, graphical resource editors, and the full power of Android Studio in all major platforms.
- Fully integrated with Android Studio and the Gradle build system.
- Includes support for coding assistance and on-demand class decompilation.
- Patch Java code in Java using declarative syntax provided by the DexPatcher tool.
- Manifest merging enables piece-wise changes to the original app manifest.
- Modify existing resources or create new ones using Android Studio's standard resource editors.
- Use Android Studio's code template wizards for creating activities, etc.
- Pull in Android libraries (a.k.a. '.aar' Android archives) and have their manifests, code and resources automatically merged into the patched app.
- And enjoy debugging support.
- All in your favorite platform: Linux, Windows or macOS.
DexPatcher tool (Dalvik bytecode patcher)
Release notes: https://github.com/DexPatcher/dexpatcher-tool/releases
Sources: https://github.com/DexPatcher/dexpatcher-tool
DexPatcher Gradle plugins (Android build system and Android Studio integration)
Release notes: https://github.com/DexPatcher/dexpatcher-gradle/releases
Artifacts: https://plugins.gradle.org/search?term=dexpatcher
Sources: https://github.com/DexPatcher/dexpatcher-gradle
Samples: https://github.com/DexPatcher/dexpatcher-gradle-samples
Deprecated tools
Release notes for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle/releases?after=v2.0.0-alpha1
Support tools for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle-tools
Workflow automation scripts (Linux-only): https://github.com/DexPatcher/dexpatcher-tool-scripts
License
GPL v3 (or later)
THANK YOU ! - The DexPatcher tool uses JesusFreke's dexlib2 (part of smali) to read and write dex files. Many thanks to him for repeatedly helping me in #smali on freenode. When creating apk libraries, the DexPatcher Gradle plugin uses iBotPeaches' Apktool to decode compiled resources and pxb1988's dex2jar to translate Dalvik bytecode. DexPatcher could not exist without the invaluable work of these guys.
Documentation
PATCHING JAVA CODE IN JAVA
The DexPatcher tool uses declarative semantics based on Java annotations to patch the bytecode of the source application. There is no formal definition but hopefully you will find everything you need in this sample:
- The sample code being patched.
- The patch itself with explanatory comments.
- The output of DexPatcher and test runs of the original and patched code.
START HERE !
With the new DexPatcher Gradle v2 plugins
Get the sample code working, here is how:
- Clone the samples.
- Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the release notes of recent versions of the Gradle plugins for more information on tool compatibility and environment setup.
In the 'patched-app' sample, browse the two 'build.gradle' files (main and app) to get an idea of what is happening. The plugins used are briefly described here. Next get inside the 'app' subproject and take a look at its manifest and resource files. These files are merged with the ones coming from the source app, which is located in the 'apk' directory. Finally look into the 'MainActivity.java' file to see how the compiled code of the app is patched using Java. This is handled by the DexPatcher tool, a key piece of the DexPatcher toolchain. See the section 'Patching Java code in Java' above for more details on this tool, and please review its recent release notes.
The DexPatcher Gradle plugins use Apktool to decode applications and optionally create APK libraries. They optionally use dex2jar to display decompiled application code and to import application code symbols into patch projects. They use the DexPatcher tool to patch the Dalvik bytecode of applications. And finally they use the Andoird build system to merge manifests, code, resources, assets, and extra files, and to repackage applications.
With the old DexPatcher Gradle v1 plugins
To get the old sample code working:
- Install the support tools by cloning the repo anywhere you like.
- Clone the 'v1' branch of the samples.
- Set the 'dexpatcher.dir=<support-tool-dir>' property in identical files named 'local.properties' in the root directory of each sample so that it points to your local clone of the support tools. Create the files if necessary, or have Android Studio create them for you by opening the samples.
- Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the old release notes of the Gradle v1 plugins for more information on tool compatibility and environment setup.
OLD NEWS: DexPatcher Featured On XDA Portal !
GermainZ wrote an excellent introductory article for XDA that walks you though the complete process of modding an app using the old deprecated Linux-only workflow automation scripts. This only covers the DexPatcher tool itself, ie: only patching of code, not resources. The workflow is deprecated, but the Java patch code and accompanying explanations are very valuable and continue to be current. I am grateful to him for having taken the time to do this. Please make sure you give it a read:
Also available: [WARNING: Deprecated, Linux-only]
LICENSING UPDATE:
tl;dr: DexPatcher patches are no longer forcefully covered by the GPL.
Recent versions of DexPatcher no longer require that users bundle the DexPatcher annotations with every patch (although continuing to do so has no ill effects). The DexPatcher licensing terms no longer impose licensing restrictions on patches, as long as users refrain from bundling the DexPatcher annotations with them. In particular, DexPatcher patches are no longer considered to be derivative works of DexPatcher and thus are no longer automatically covered by the GPL. Legals aside, the DexPatcher project urges you not to use copyright laws to introduce artificial scarcity in the world. Please give back to the community: share your work.
XDA:DevDB Information
DexPatcher, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/DexPatcher
Version Information
Status: Stable
Created 2015-03-21
Last Updated 2019-11-096UPDATE: DexPatcher-gradle v1.0.0 is out, finally!
also, the 'patched-dex' sample has been heavily updated to match.
https://github.com/DexPatcher/dexpatcher-gradle/releases
https://github.com/DexPatcher/dexpatcher-gradle-samples/blob/master/patched-dex/build.gradle5The Big TO-DO List
The Big TO-DO List
...of things I would like done in this project, but that I will probably not have the time to implement myself.
DexPatcher-tool
Moved here: https://github.com/Lanchon/DexPatcher-tool/issues
DexPatcher-gadle
Moved here: https://github.com/Lanchon/DexPatcher-gradle/issues
DexPatcher and javac
- Modify javac so that all source symbols -even those defined inside edited classes- are available during compilation. This could produce a patched javac executable, or the standard javac could be patched in-memory using java agents, or its in-memory data structures hacked from an annotation processor (a la Project Lombok).
- Decide if dex2jar and jar2dex/dx are transparent and mature enough to move DexPatcher 2.0 to the java bytecode realm, and stop operating at the dalvik bytecode level. [UPDATE: It is not.] Or a VM abstraction could be implemented as a backend to DexPatcher so that the same font end could be used for both dex and class files.
- If the project is moved to the java bytecode realm, decide if the new DexPatcher should be a standalone tool like it is today, or a java agent/annotation processor that modifies javac to do the patching during compile time. This would make the tool very easy to integrate into most build systems.
4DEPRECATED: Workflow Automation Scripts HOW-TO
DEPRECATED: Workflow Automation Scripts HOW-TO
These scripts bundle several tools (including DexPatcher) and automate boilerplate actions that are part of a typical workflow. They are available only for Linux. Take the leap today, get yourself free, get Linux Mint Cinnamon 64-bit.
Installation
Code:# cd to a suitable install dir such as '~/opt' or '~/android/tools'. git clone [url]https://github.com/Lanchon/DexPatcher-scripts.git[/url] dexpatcher cd dexpatcher chmod +x dxp-* # edit 'dxp.config': # -set the path to android sdk (defaults to '~/android/sdk'). # -disable bundled tools to use the ones in $PATH if desired. # add 'dxp-*' scripts to $PATH: # -symlink the 'dxp-*' scripts in a suitable dir in the $PATH such as '~/bin'. # -or add the 'dexpatcher' dir to $PATH.
Sample Workflow
Code:# cd to a suitable workspace dir. dxp-setup-for-apk path/to/TheApk.apk cd TheApk dxp-create-keystore # in 'src-cfr' you will find decompilation of the app to Java (with errors). # you can use these files to plan your changes. # in 'src-cfr-nocode' you will find decompilation of empty method stubs. # you can use selected files as a basis for your patch. # create your patch as Java files in 'src'. # the symbols of the original app will be accessible to your patch code. dxp-make adb install -r patched.apk
