社区
Android
帖子详情
使用re-sign.jar重签APK,报ERROR是为啥
pataka
2015-04-22 11:01:48
请教个问题
使用re-sign.jar重签APK,报ERROR:Expected chunk of type 0x80003,read 0x6d783f3c,是为啥?如何解决
...全文
186
1
打赏
收藏
使用re-sign.jar重签APK,报ERROR是为啥
请教个问题 使用re-sign.jar重签APK,报ERROR:Expected chunk of type 0x80003,read 0x6d783f3c,是为啥?如何解决
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
1 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
qq_28185695
2015-06-10
打赏
举报
回复
我看这个问题 好多人问,居然一个回答的都没有,看来都是假大师
apk
tool documentation
https://github.com/iBotPeaches/
Apk
tool Introduction Basic First lets take a lesson into
apk
files.
apk
s are nothing more than a zip file containing resources and compiled java. If you were to simply unzip an
apk
like so, you would be left with files such as classes.dex and resources.arsc. $ unzip testapp.
apk
Archive: testapp.
apk
inflating: AndroidManifest.xml inflating: classes.dex extracting: res/drawable-hdpi/ic_launcher.png inflating: res/xml/literals.xml inflating: res/xml/references.xml extracting: resources.arsc However, at this point you have simply inflated compiled sources. If you tried to view AndroidManifest.xml. You'd be left viewing this. P4F0\fnversionCodeversionNameandroid*http://schemas.android.com/
apk
/res/androidpackageplatformBuildVersionCodeplatformBuildVersionNamemanifestbrut.
apk
tool.testapp1.021
APK
TOOL Obviously, editing or viewing a compiled file is next to impossible. That is where
Apk
tool comes into play. $
apk
tool d testapp.
apk
I: Using
Apk
tool 2.0.0 on testapp.
apk
I: Loading resource table... I: Decoding AndroidManifest.xml with resources... I: Loading resource table from file: 1.
apk
I: Regular manifest package... I: Decoding file-resources... I: Decoding values */* XMLs... I: Baksmaling classes.dex... I: Copying assets and libs... $ Viewing AndroidManifest.xml again results in something much more human readable In addition to XMLs, resources such as 9 patch images, layouts, strings and much more are correctly decoded to source form. Decoding The decode option on
Apk
tool can be invoked either from d or decode like shown below. $
apk
tool d foo.
jar
// decodes foo.
jar
to foo.
jar
.out folder $
apk
tool decode foo.
jar
// decodes foo.
jar
to foo.
jar
.out folder $
apk
tool d bar.
apk
// decodes bar.
apk
to bar folder $
apk
tool decode bar.
apk
// decodes bar.
apk
to bar folder $
apk
tool d bar.
apk
-o baz // decodes bar.
apk
to baz folder Building The build option can be invoked either from b or build like shown below $
apk
tool b foo.
jar
.out // builds foo.
jar
.out folder into foo.
jar
.out/dist/foo.
jar
file $
apk
tool build foo.
jar
.out // builds foo.
jar
.out folder into foo.
jar
.out/dist/foo.
jar
file $
apk
tool b bar // builds bar folder into bar/dist/bar.
apk
file $
apk
tool b . // builds current directory into ./dist $
apk
tool b bar -o new_bar.
apk
// builds bar folder into new_bar.
apk
$
apk
tool b bar.
apk
// WRONG: brut.androlib.AndrolibException: brut.directory.PathNotExist:
apk
tool.yml // Must use folder, not
apk
/
jar
file InfoIn order to run a rebuilt application. You must re
sign
the application. Android documentation can help with this. Frameworks Frameworks can be installed either from if or install-framework, in addition two parameters -p, --frame-path - Store framework files into -t, --tag - Tag frameworks using Allow for a finer control over how the files are named and how they are stored. $
apk
tool if framework-res.
apk
I: Framework installed to: 1.
apk
// pkgId of framework-res.
apk
determines number (which is 0x01) $
apk
tool if com.htc.resources.
apk
I: Framework installed to: 2.
apk
// pkgId of com.htc.resources is 0x02 $
apk
tool if com.htc.resources.
apk
-t htc I: Framework installed to: 2-htc.
apk
// pkgId-tag.
apk
$
apk
tool if framework-res.
apk
-p foo/bar I: Framework installed to: foo/bar/1.
apk
$
apk
tool if framework-res.
apk
-t baz -p foo/bar I: Framework installed to: foo/bar/1-baz.
apk
Migration Instructions v2.1.1 -> v2.2.0 Run the following commands to migrate your framework directory
Apk
tool will work fine without running these commands, this will just cleanup abandoned files unix - mkdir -p ~/.local/share; mv ~/
apk
tool ~/.local/share windows - move %USERPROFILE%\
apk
tool %USERPROFILE%\AppData\Local v2.0.1 -> v2.0.2 Update
apk
tool to v2.0.2 Remove framework file $HOME/
apk
tool/framework/1.
apk
due to internal API update (Android Marshmallow) v1.5.x -> v2.0.0 Java 1.7 is required Update
apk
tool to v2.0.0 aapt is now included inside the
apk
tool binary. It's not required to maintain your own aapt install under $PATH. (However, features like -a / --aapt are still used and can override the internal aapt) The addition of aapt replaces the need for separate aapt download packages. Helper Scripts may be found here Remove framework $HOME/
apk
tool/framework/1.
apk
Eagle eyed users will notice resources are now decoded before sources now. This is because we need to know the API version via the manifest for decoding the sources Parameter Changes Smali/baksmali 2.0 are included. This is a big change from 1.4.2. Please read the smali updates here for more information -o / --output is now used for the output of
apk
/directory -t / --tag is required for tagging framework files -advance / --advanced will launch advance parameters and information on the usage output -m / --match-original is a new feature for
apk
analysis. This retains the
apk
is nearly original format, but will make rebuild more than likely not work due to ignoring the changes that newer aapt requires After [d]ecode, there will be new folders (original / unknown) in the decoded
apk
folder original = META-INF folder / AndroidManifest.xml, which are needed to retain the
sign
ature of
apk
s to prevent needing to re
sign
. Used with -c / --copy-original on [b]uild unknown = Files / folders that are not part of the standard AOSP build procedure. These files will be injected back into the rebuilt
APK
.
apk
tool.yml collects more information than last version SdkInfo - Used to repopulate the sdk information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter packageInfo - Used to help support Android 4.2 renamed manifest feature. Automatically detects differences between resource and manifest and performs automatic --rename-manifest-package on [b]uild versionInfo - Used to repopulate the version information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter compressionType - Used to determine the compression that resources.arsc had on the original
apk
in order to replicate during [b]uild unknownFiles - Used to record name/location of non-standard files in an
apk
in order to place correctly on rebuilt
apk
sharedLibrary - Used to help support Android 5 shared library feature by automatically detecting shared libraries and using --shared-lib on [b]uild Examples of new usage in 2.0 vs 1.5.x Old (
Apk
tool 1.5.x) New (
Apk
tool 2.0.x)
apk
tool if framework-res.
apk
tag
apk
tool if framework-res.
apk
-t tag
apk
tool d framework-res.
apk
output
apk
tool d framework.res.
apk
-o output
apk
tool b output new.
apk
apk
tool b output -o new.
apk
v1.4.x -> v1.5.1 Update
apk
tool to v1.5.1 Update aapt manually or use package r05-ibot via downloading Mac, Windows or Linux Remove framework file $HOME/
apk
tool/framework/1.
apk
Intermediate Framework Files As you probably know, Android apps utilize code and resources that are found on the Android OS itself. These are known as framework resources and
Apk
tool relies on these to properly decode and build
apk
s. Every
Apk
tool release contains internally the most up to date AOSP framework at the time of the release. This allows you to decode and build most
apk
s without a problem. However, manufacturers add their own framework files in addition to the regular AOSP ones. To use
apk
tool against these manufacturer
apk
s you must first install the manufacturer framework files. Example Lets say you want to decode HtcContacts.
apk
from an HTC device. If you try you will get an
error
message. $
apk
tool d HtcContacts.
apk
I: Loading resource table... I: Decoding resources... I: Loading resource table from file: 1.
apk
W: Could not decode attr value, using undecoded value instead: ns=android, name=drawable W: Could not decode attr value, using undecoded value instead: ns=android, name=icon Can't find framework resources for package of id: 2. You must install proper framework files, see project website for more info. We must get HTC framework resources before decoding this
apk
. We pull com.htc.resources.
apk
from our device and install it $
apk
tool if com.htc.resources.
apk
I: Framework installed to: 2.
apk
Now we will try this decode again. $
apk
tool d HtcContacts.
apk
I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/
apk
tool/framework/1.
apk
I: Loading resource table from file: /home/brutall/
apk
tool/framework/2.
apk
I: Copying assets and libs... As you can see.
Apk
tool leveraged both 1.
apk
and 2.
apk
framework files in order to properly decode this application. Finding Frameworks For the most part any
apk
in /system/framework on a device will be a framework file. On some devices they might reside in /data/system-framework and even cleverly hidden in /system/app or /system/priv-app. They are usually named with the naming of "resources", "res" or "framework". Example HTC has a framework called com.htc.resources.
apk
, LG has one called lge-res.
apk
After you find a framework file you could pull it via adb pull /path/to/file or use a file manager application. After you have the file locally, pay attention to how
Apk
tool installs it. The number that the framework is named during install corresponds to the pkgId of the application. These values should range from 1 to 9. Any
APK
that installs itself as 127 is 0x7F which is an internal pkgId. Internal Frameworks
Apk
tool comes with an internal framework like mentioned above. This file is copied to $HOME/
apk
tool/framework/1.
apk
during use. Warning
Apk
tool has no knowledge of what version of framework resides there. It will assume its up to date, so delete the file during
Apk
tool upgrades Managing framework files Frameworks are stored in $HOME/
apk
tool/framework for Windows and Unix systems. Mac OS X has a slightly different folder location of $HOME/Library/
apk
tool/framework. If these directories are not available it will default to java.io.tmpdir which is usually /tmp. This is a volatile directory so it would make sense to take advantage of the parameter --frame-path to select an alternative folder for framework files. Note
Apk
tool has no control over the frameworks once installed, but you are free to manage these files on your own. Tagging framework files Frameworks are stored in the naming convention of: -.
apk
. They are identified by pkgId and optionally custom tag. Usually tagging frameworks isn't necessary, but if you work on apps from many different devices and they have incompatible frameworks, you will need some way to easily switch between them. You could tag frameworks by: $
apk
tool if com.htc.resources.
apk
-t hero I: Framework installed to: /home/brutall/
apk
tool/framework/2-hero.
apk
$
apk
tool if com.htc.resources.
apk
-t desire I: Framework installed to: /home/brutall/
apk
tool/framework/2-desire.
apk
Then: $
apk
tool d HtcContacts.
apk
-t hero I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/
apk
tool/framework/1.
apk
I: Loading resource table from file: /home/brutall/
apk
tool/framework/2-hero.
apk
I: Copying assets and libs... $
apk
tool d HtcContacts.
apk
-t desire I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/
apk
tool/framework/1.
apk
I: Loading resource table from file: /home/brutall/
apk
tool/framework/2-desire.
apk
I: Copying assets and libs... You don't have to select a tag when building
apk
-
apk
tool automatically uses the same tag, as when decoding. Smali Debugging Warning SmaliDebugging has been marked as deprecated in 2.0.3, and removed in 2.1. Please check SmaliIdea for a debugger.
Apk
tool makes possible to debug smali code step by step, watch variables, set breakpoints, etc. General information Generally we need several things to run Java debugging session: debugger server (usually Java VM) debugger client (usually IDE like IntelliJ, Eclipse or Netbeans) client must have sources of debugged application server must have binaries compiled with debugging symbols referencing these sources sources must be java files with at least package and class definitions, to properly connect them with debugging symbols In our particular situation we have: server: Monitor (Previously DDMS), part of Android SDK, standard for debugging Android applications - explained here client: any JPDA client - most of decent IDEs have support for this protocol. sources: smali code modified by
apk
tool to satisfy above requirements (".java" extension, class declaration, etc.).
Apk
tool modifies them when decoding
apk
in debug mode. binaries: when building
apk
in debug mode,
apk
tool removes original symbols and adds new, which are referencing smali code (line numbers, registers/variables, etc.) Info To successfully run debug sessions, the
apk
must be both decoded and built in debug mode. Decoding with debug decodes the application differently to allow the debug rebuild option to inject lines allowing the debugger to identify variables and types.-d / --debug General instructions Above information is enough to debug smali code using
apk
tool, but if you aren't familiar with DDMS and Java debugging, then you probably still don't know how to do it. Below are simple instructions for doing it using IntelliJ or Netbeans. Decode
apk
in debug mode: $
apk
tool d -d -o out app.
apk
Build new
apk
in debug mode: $
apk
tool b -d out
Sign
, install and run new
apk
. Follow sub-instructions below depending on IDE. IntelliJ (Android Studio) instructions In IntelliJ add new Java Module Project selecting the "out" directory as project location and the "smali" subdirectory as content root dir. Run Monitor (Android SDK /tools folder), find your application on a list and click it. Note port information in last column - it should be something like "86xx / 8700". In IntelliJ: Debug -> Edit Configurations. Since this is a new project, you will have to create a Debugger. Create a Remote Debugger, with the settings on "Attach" and setting the Port to 8700 (Or whatever Monitor said). The rest of fields should be ok, click "Ok". Start the debugging session. You will see some info in a log and debugging buttons will show up in top panel. Set breakpoint. You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#". Trigger some action in application. If you run at breakpoint, then thread should stop and you will be able to debug step by step, watch variables, etc. Netbeans instructions In Netbeans add new Java Project with Existing Sources, select "out" directory as project root and "smali" subdirectory as sources dir. Run DDMS, find your application on a list and click it. Note port information in last column - it should be something like "86xx / 8700". In Netbeans: Debug -> Attach Debugger -> select JPDA and set Port to 8700 (or whatever you saw in previous step). Rest of fields should be ok, click "Ok". Debugging session should start: you will see some info in a log and debugging buttons will show up in top panel. Set breakpoint. You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#". Trigger some action in application. If you run at breakpoint, then thread should stop and you will be able to debug step by step, watch variables, etc. Limitations/Issues Because IDE doesn't have full sources, it doesn't know about class members and such. Variables watching works because most of data could be read from memory (objects in Java know about their types), but if for example, you watch an object and it has some nulled member, then you won't see, what type this member is. 9Patch Images Docs exist for the mysterious 9patch images here and there. (Read these first). These docs though are meant for developers and lack information for those who work with already compiled 3rd party applications. There you can find information how to create them, but no information about how they actually work. I will try and explain it here. The official docs miss one point that 9patch images come in two forms: source & compiled. source - You know this one. You find it in the source of an application or freely available online. These are images with a black border around them. compiled - The mysterious form found in
apk
files. There are no borders and the 9patch data is written into a binary chunk called npTc. You can't see or modify it easily, but Android OS can as its quicker to read. There are problems related to the above two points. You can't move 9patch images between both types without a conversion. If you try and unpack 9patch images from an
apk
and use it in the source of another, you will get
error
s during build. Also vice versa, you cannot take source 9patch images directly into an
apk
. 9patch binary chunk isn't recognized by modern image processing tools. So modifying the compiled image will more than likely break the npTc chunk, thus breaking the image on the device. The only solution to this problem is to easily convert between these two types. The encoder (which takes source to compiled) is built into the aapt tool and is automatically used during build. This means we only need to build a decoder which has been in
apk
tool since v1.3.0 and is automatically ran on all 9patch images during decode. So if you want to modify 9patch images, don't do it directly. Use
apk
tool to decode the application (including the 9patch images) and then modify the images. At that point when you build the application back, the source 9patch images will be compiled. Other FAQ What about the -j switch shown from the original YouTube videos? Read Issue 199. In short - it doesn't exist. Is it possible to run
apk
tool on a device? Sadly not. There are some incompatibilities with SnakeYAML, java.nio and aapt Where can I download sources of
apk
tool? From our Github or Bitbucket project. Resulting
apk
file is much smaller than original! Is there something missing? There are a couple of reasons that might cause this.
Apk
tool builds un
sign
ed
apk
s. This means an entire directory META-INF is missing. New aapt binary. Newer versions of
apk
tool contain a newer aapt which optimizes images differently. These points might have contributed to a smaller than normal
apk
There is no META-INF dir in resulting
apk
. Is this ok? Yes. META-INF contains
apk
sign
atures. After modifying the
apk
it is no longer
sign
ed. You can use -c / --copy-original to retain these
sign
atures. However, using -c uses the original AndroidManifest.xml file, so changes to it will be lost. What do you call "magic
apk
s"? For some reason there are
apk
s that are built using modified build tools. These
apk
s don't work on a regular AOSP Android build, but usually are accompanied by a modified system that can read these modified
apk
s.
Apk
tool cannot handle these
apk
s, therefore they are "magic". Could I integrate
apk
tool into my own tool? Could I modify
apk
tool sources? Do I have to credit you? Actually the Apache License, which
apk
tool uses, answers all these questions. Yes you can redistribute and/or modify
apk
tool without my permission. However, if you do it would be nice to add our contributors (brut.all, iBotPeaches and JesusFreke) into your credits but it's not required. Where does
apk
tool store its framework files? unix - $HOME/.local/share/
apk
tool mac - $HOME/Library/
apk
tool windows - $HOME/AppData/Local/
apk
tool Options Utility Options that can be executed at any time. -version, --version Outputs current version. (Ex: 1.5.2) -v, --verbose Verbose output. Must be first parameter -q, --quiet Quiet output. Must be first parameter -advance, --advanced Advance usage output Decode These are all the options when decoding an
apk
. --api The numeric api-level of the smali files to generate (defaults to targetSdkVersion) -b, --no-debug-info Prevents baksmali from writing out debug info (.local, .param, .line, etc). Preferred to use if you are comparing smali from the same
APK
of different versions. The line numbers and debug will change among versions, which can make DIFF reports a pain. -f, --force Force delete destination directory. Use when trying to decode to a folder that already exists --keep-broken-res - Advanced If there is an
error
like "Invalid Config Flags Detected. Dropping Resources...". This means that
APK
has a different structure then
Apk
tool can handle. This might be a newer Android version or a random
APK
that doesn't match standards. Running this will allow the decode, but then you have to manually fix the folders with -ERR in them. -m, --match-original - Used for analysis Matches files closest as possible to original, but prevents rebuild. -o, --output The name of the folder that
apk
gets written to -p, --frame-path The folder location where framework files should be stored/read from -r, --no-res This will prevent the decompile of resources. This keeps the resources.arsc intact without any decode. If only editing Java (smali) then this is the recommend for faster decompile & rebuild -s, --no-src This will prevent the disassemble of the dex files. This keeps the
apk
classes.dex file and simply moves it during build. If your only editing the resources. This is recommended for faster decompile & rebuild -t, --frame-tag Uses framework files tagged via Rebuild These are all the options when building an
apk
. -a, --aapt Loads aapt from the specified file location, instead of relying on path. Falls back to $PATH loading, if no file found -c, --copy-original - Will still require
sign
ature re
sign
post API18 Copies original AndroidManifest.xml and META-INF folder into built
apk
-d, --debug Adds debuggable="true" to AndroidManifest file. -f, --force-all Overwrites existing files during build, reassembling the resources.arsc file and classes.dex file -o, --output The name and location of the
apk
that gets written -p, --frame-path The location where framework files are loaded from
apk
tool 2.3.0
Apk
tool反汇编工具,支持反汇编
apk
文件,也能重新打包生成
apk
,很好用
AabResGuard:The tool of obfuscated aab resources.(Android app bundle资源混淆工具)
AabResGuard 混淆的AAB资源的工具 | 由bytedance douyin安卓团队提供技术支持。 特征 混淆了aab资源的工具。 合并重复的资源:合并重复的资源文件以减小程序包的大小。 过滤捆绑包文件:支持过滤bundle包中的文件。 当前仅支持在MATE-INFO/和lib/路径中进行过滤。 白名单:白名单中的资源不会被混淆。 增量混淆:输入mapping文件以支持增量混淆。 删除字符串:输入未
使用
的文件,按行分割以支持删除字符串。 ???:展望未来,将会有更多功能支持,欢迎提交PR&问题。 AabResGuard是由douyin Android团队提供支持的资源混淆工具。 它已于2018年7月底在Tiktok,Vigo等多种海外产品中推出。关于相关资源问题,没有反馈。 有关更多数据的详细信息,请转到。 快速开始 命令工具:支持命令行。 Gradle插件:
mac下自己实现re-
sign
.
jar
对
apk
进行
重签
名
利用Robotinum对给的
apk
文件进行自动化测试,在不知道源码的情况下,只有
apk
文件如何进行自动化测试呢? 首先需要对
apk
文件进行
重签
名,并获得该
apk
文件的包名和程序入口的类名。 最开始网上说用re-
sign
.
jar
这个
jar
包,但是我用mac电脑实验了很多次都不行,一直提示JAVA_HOME环境变量没有设置,可是我已经设置了,echo $PATH输出也能看到J...
re-
sign
和aapt的
使用
规则
一。re-
sign
.
jar
的
使用
流程。 最重要的下面这几步,一定要明白,一定要清楚这些步骤。 1.配置android环境 (1)右击我的电脑-->属性-->高级-->环境变量-->系统变量-- >添加android_home:H:\adt-bundle-windows-x86-20131030\sdk 切记这里最后没有分号 (2)系统变量的path点击编辑,然后添加%ANDROID_H
Android
80,471
社区成员
91,385
社区内容
发帖
与我相关
我的任务
Android
移动平台 Android
复制链接
扫一扫
分享
社区描述
移动平台 Android
android
android-studio
androidx
技术论坛(原bbs)
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章