無標題文檔

Android 的 apk 包的反编译和破解初步

_注:此信息仅仅是作为技术研究使用,请勿用作非法用途。同时本团队的应用已经针对破
解有了对应的措施,并保留追求责任的权利。_

前些日子看到公司的应用被破解同时在论坛里流出,所以了解了下 Android 相应的应用破解原理以及过程。

首先,下载相应解开 apk 的工具包:

https://code.google.com/p/android-apktool/

下载完了以后得到个 jar 包,我们运行

java -jar apktool.jar

就可以得到它的用法。我这边直接解压缩相应的 apk 包:

java -jar apktool.jar decode origin-v1.0.apk

解压完毕以后,在本地目录就可以看到多出来个文件夹,里面包含了 apk 的原始资源等数据。

https://friable.rocks/_/2013_11_28/1385608157@640.png

其中,最重要的就是 smali 目录,它对应的是原始 Android 项目的 src 目录,也就是 Java 源文件。不过 smali 有点类似「Java 的汇编」,详细有关 smali 的信息可以在这里得到:

https://code.google.com/p/smali/

下面,比如我们已经知道原来应用注册的位置,例如 Activity 的入口,那么我们就从这里开始切入。

https://friable.rocks/_/2013_11_28/1385608119.png

我们很容易得就能得到相应的激活注册模块的方法在哪里,例如下面的 parseActive 方法就是判断 JSONObject 是否包含了注册信息。

.method public static parseActive(Lorg/json/JSONObject;)Lcn/dxy/android/medicinehelper/api/model/Active;

从大体的阅读源码来看,这个方法主要的功能就是解析服务器返回的 JSON 信息,然后根据返回判断是否注册。那么,我的思路就是修改方法,无论服务器返回什么都返回已经注册。

https://friable.rocks/_/2013_11_28/1385608183.png

看程序代码段中,有段为

.line 35
const-string v3, "active"

invoke-static {p0, v3, v4}, Lcn/dxy/sso/util/AppUtil;->getJsonBooleanValue(Lorg/json/JSONObject;Ljava/lang/String;Z)Z

move-result v1

.line 36
.local v1, active:Z
if-nez v1, :cond_0

.line 37
invoke-static {p0}, Lcn/dxy/sso/entity/ErrorType;->constructErrorBody(Lorg/json/JSONObject;)Lcn/dxy/sso/entity/ErrorType;

move-result-object v2

其中,有个语句 if-nez v1, :cond_0 很关键,因为这个语句下面就是错误信息了(v1 的值是 JSONOBject 过来的 activte 字段的内容)。那么可以判断,这个 if 就是主要判断语句,写成伪代码也就是

if (!active) {
    showError();
    return;
}

// Activited

所以我将这个判断的内容始终改成 true,查询 smali 的语法,简单的修改如下

if-eqz v1, :cond_0

也就是做了个相反的判断,虽然这样子正常的激活码就无法注册,但根据逻辑只要输入格式对应的激活码都可以激活了。

修改完成了以后我们需要重新打包成 apk 文件,这里还是要用到上述的 apktool 工具,做个相反的操作即可:

java -jar apktool.jar build <origin-v1.0-dir> new-v1.0.apk

注意,这时通过 apktool 生成的 apk 文件是没有经过签名的,直接 adb install 是无法
安装的,会报 INSTALL_PARSE_FAILED_NO_CERTIFICATES 错误。

因此,我们需要将其前面以后再安装,这里有 Google 相应的文档阐述如何签名 apk 包:


https://developer.android.com/tools/publishing/app-signing.html

当然使用了自定义前面的 apk 包以后您就无法安装和升级官方的 apk 包了。

https://friable.rocks/_/2013_11_28/1385608067@640.png

完成上述步骤了以后,我们安装打开已经经过修改的应用,发现随便输入任何激活码就可以完成本地激活了。

- eof -

Volley 使用笔记

Google I/O 2013 上就讲到了 Volley。当时并没还有在意这个类库,直到看了某项目的源代码后,发现这个东西值得推荐。

Volley 这个库的官方介绍是:

Volley is a library that makes networking for Android apps
easier and most importantly, faster.

不是很严谨的讲,Volley 就是个包含了很多封装功能的网络请求工具类。使用这个工具类有个优势就是可以节省很多在请求以及缓存方面的开发时间。

优势

[相比其他网络载入类库](https://github.com/nostra13/Android-Universal-Image-Loader
),Volley 的优势官方主要提到如下几点:

  1. 队列网络请求,并自动合理安排何时去请求。
  2. 提供了默认的磁盘和内存等缓存(Disk Caching & Memory Caching)选项。
  3. Volley 可以做到高度自定义,它能做到的不仅仅是缓存图片等资源。
  4. Volley 相比其他的类库更方便调试和跟踪。

基本使用

引入 Volley 很简单。使用 git 下载代码到本地

git clone https://android.googlesource.com/platform/frameworks/volley

然后引入到项目中就可以使用了。

Volley 简单的来讲主要由两个类控制:

  1. Request Queue
  2. Request

Volley 的「Hello,World」示例代码:

// 实例化 Request Queue
RequestQueue queue = Volley.newRequestQueue(context);

// 实例化 Request
String url = "<remote url>";
JsonObjectRequest jsonObjRequest =
    new JsonObjectRequest(Request.Method.GET, url, null, new Response.Listener<JSONObject>() {

        @Override
        public void onResponse(JSONObject response) {
            // ...
        }
    }, new Response.ErrorListener() {

        @Override
        public void onErrorResponse(VolleyError error) {
            // ...

        }
    });

然后剩下要做的事情就是把这个 Request 扔到 Queue 里面即可:

queue.add(jsonObjRequest);

缓存图片资源

缓存图片资源 Volley 提供了个自定义的 NetworkImageView 继承自 ImageView 。它的优势就是载入远程图片几乎可以用「傻瓜」形容,例如:

mNetworkImageView.setImageUrl(imageUrl, new ImageLoader());

其中 ImageLoader 最重要的一个参数就是 ImageLoader.ImageCache 它控制是否需要请求网络获取数据。因此,我们可以将这个 Class 配合 LruCache 以及 DiskLruCache 用来内存和磁盘缓存。

主要方法

@Override
public Bitmap getBitmap(String url) {
    Bitmap data = mLruCache.get(url);
    if (data == null) {
        try {
            data = mDiskLruCache.get(key);
            if (data != null) {
                mLruCache.put(key, data);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    } 

    return data;
}

这样子,就可以很清晰得把内存缓存和磁盘缓存之间的关系建立和链接起来了。

资源&参考

- eof -

使用命令行截取 Android 设备的界面

在进行 Android 开发的时候有时候需要截图,通常我的土办法就是打开 DDMS 然后再截取,这样有点不好就是效率不高每次都需要刷新然后手工去保存。

搜索了下,发现 [Linux 下已经有现成的解决方案](http://blog.shvetsov.com/2013/02/grab-android-screenshot-to-computer-via.html
)。原理就是使用使用 Android 自带的命令行 screencap 然后通过 adb 传输过来。

整条 Shell 命令其实很简单

adb shell screencap -p | sed 's/\r$//' > outputs.png

但发现在我的 Mac 无法运行。检查了以后发现是 GNU sed 和 BSD sed 命令间有不兼容的情况。我的解决方案就是使用 brew 安装 gsed(有更好的解决方案的同学欢迎指出)。

brew install gnu-sed

然后简单得修改下上面的 Shell 脚本:

adb shell screencap -p | gsed 's/\r$//' > ~/Desktop/`date +%Y%m%d%H%M%S.png`

这样子每次运行这个脚本就能把 Android 设备的截图放到桌面了,并自动命名。

UPDATE .1

原博客的作者也给出了在 Mac 下的解决方案,他是使用 Perl :

adb shell screencap -p | perl -pe 's/\x0D\x0A/\x0A/g' > screen.png

这样子对于没有安装 brew 的同学是个好消息。

-- EOF --

又一款 Android 应用:「读知乎」

NOTE:因为没有得到「知乎」官方的许可,这款应用长期无法在国内市场上架,因此暂停开发。
同时也不保证能够正常读取「知乎」条目,在这里我表示遗憾和抱歉。

同时开放源代码,参见:https://github.com/feelinglucky/iZhihu

--

慢慢的从刷「微博」的习惯改成了刷「知乎」,相对比而言我觉得这比在「微博」上更有意义。

「读知乎」这个应用首先是 小虎 开发对应的 iOS 版,然后 小虎 说应该有个 Android 版本,刚好本人会一点点的 Android 开发,于是就有了这个应用。

Preference Screen

写这个应用没有花很多时间,甚至线框图都没有画过根据 iOS 版照葫芦画瓢就做了出来。不过慢慢的发现我需要更多的功能,然后慢慢得在正面叠加功能。

于是:

等等的这些功能是典型的个人需求驱动的开发,但愿这些繁杂的功能没有让其他使用者茫然无措。

--

从着手开发到现在已经过了两个月时间,对于某些是用过的东西有了更多的印象。在这里说下我这里的心得吧,仅仅是些个人的观点:

知乎

知乎上的内容很好,甚至我有点强迫症式的会刷知乎上的条目(好吧,我承认这是强迫症的表现之一)。

从知乎站点的页面设计上说,知乎的页面其实并不适合阅读。所以,每次阅读我感兴趣的条目时,都要「Command + +」增大字体阅读。

同时,知乎目前并没有开放的 API(据说也没有具体的计划开放 API)。这对于开发者而言非常的不友好,但知乎官方对应的「知乎」、「知乎日报」等应用都采用了知乎自己的私有接口。

其实这让「读知乎」在数据源方面的问题非常的尴尬。一方面「读知乎」的数据是取自知乎站点,并保持同步更新;另一方面,知乎没有明确的条款说明这些数据的版权以及使用方面的等问题。

BAE

「读知乎」的后台使用的是 BAE(百度应用引擎)http://developer.baidu.com/bae ,总体来讲这是个非常不错的应用平台。由于「读知乎」用户数量的增长,我们也体验了下 BAE 平台的收费服务,总体而言体验方面并不差。

对于以前传统的自己建立服务器然后写服务器端的应用,这些应用引擎提供了更加稳定和强大的空间,对此考虑以后的 B/S 应用可以尝试迁移到类似的平台,费用算起来其实并不高。

--

Main Screenshots

PS,有关源代码方面。本来是想计划开放源代码的,但由于知乎的私有接口以及其他方面的等问题,暂时就先不开源了,这里表示下抱歉。

下面是「读知乎」的下载渠道:

-- EOF --

Android 各应用市场后台发布对比和总结

更新记录

前言

对于 Android 开发者而言,除了适配那众多的机型以外,在各市场上发布应用也仍然是非常巨大的挑战。

通过发布公司的项目以及本人编写的 Android 应用,前前后后和不少的市场打多很多交道,这里我主要总结下个人对于那众多 Android 应用市场的印象。

为了不做广告,这里的市场统一都只使用名字,不加链接。请谅解。PS,这里打分的总分都是 10 分。

各市场印象

Google Play Market

Google 官方的应用市场,初次登录市场需要 25$ 的费用,同时不能使用国内的信用卡以及需要个国外地址。新版的后台想对比较老版的好用,支持多语言、用户反馈、统计信息等功能,想对其他市场而言 Google Play Market 是标杆。

应用汇

通过渠道包以及等跟踪,应用汇的下载量和访问量不低。界面一般,功能方面能提供的都不少,但不会给你带来惊喜,总体而言应用汇的开发者后台属于中规中矩的感觉。

安卓市场(91市场)

安卓市场被 91 收购了以后界面变得「洋气」了不少,总体而言界面在国内市场中属于中上乘不为过。功能服务方面提供了「应用测试」(使用第三方 Testin 云测)服务,但需要手工提交。审核的速度一般同时想对比较宽松,一般两个工作日以后就可以审核通过。

安智市场

如果不是发布安卓应用,我第一眼打开这个市场的后台以为回到了上个世纪的九十年代,界面可以用一个字「烂」两个字「很烂」三个字「非常烂」来形容。发布和审核都需要输入验证码,同时在其他细节方面,例如多图上传需要额外的耐心。总之,在这个市场发布应用,你需要更多的耐心。

EOE(优亿)市场

优亿市场的下载量不少,但后台的界面在我审美看来只能说一般。功能方面也是中规中矩,不过初次开发者认证的速度比较慢,需要额外的耐心。

机锋市场

如果你在机锋市场上审核不通过,您可以考虑直接联系负责人。通常来讲,我对这个市场的印象就是碰到问题不要尝试自己解决,直接联系他们的负责人通常会有个更好的结果。对,在我看来机锋市场更像是个线下的市场。

界面和功能想对来讲一般,同时机锋市场提供了收费的 SDK 和 API(有谁尝试使用过?),这个算起来是他们的特色吧。

N多市场

这个应用市场的在我眼里的存在感不高,不过下载量很客观。总体而言,属于中规中矩。

木蚂蚁

相对来讲存在感并不强的市场,但并不影响将自己的应用发一份上去。使用这个市场的体验也是中规中矩,没有出太大的问题也没有什么惊喜。

网易应用

在几大门户开的运营商市场中,简单的尝试下了网易的应用市场。前期网易市场不能自己提交应用,只是靠抓取。个人感觉网易应用市场的人员不多,因为人工响应的速度想对比较慢,但一般的问题尝试自己搞定还是可以的。

豌豆荚市场

豌豆荚前期只是做应用搜索,近期似乎能够允许用户上传提交应用了。

总体而言该市场的审核比较严格,无论是登录开发者认证还是新的应用提交都需要上传相关的证件,所以在提交应用的时候需要准备好额外的资料,截至目前(2013年5月23日)我的个个人开发的应用还是没有通过审核,很残念。

界面方面比较简洁,但是不知道为什么会同时标注中文和英文双语,虽然不影响使用但是个人感觉很「装逼」,同时有少部分的文案错误但不影响使用。

同时豌豆荚市场似乎目前还不支持应用认领,如果你在豌豆荚中能够搜索到自己的应用,但还是需要你自己再重新提交下。目前(2013年5月23日)我不知道如何处理重复的应用,因为我还没有在这个市场上审核通过的经验。

魅族开发者后台

初次登录魅族市场会比较的困惑,在交互方面魅族开发者后台并不友好。例如,你更新你的软件需要「添加新版本」操作。同时你可能会对「应用列表」以及「版本列表」感到困惑,这点方面你需要学习时间。

在素材的准备方面,最好建议你手头上有台魅族手机单独给这个市场截图,因为魅族的分辨率想对来讲很「与众不同」。同时,可能你需要重新调整你的应用图标大小「96x96」以及「106x106」的大小在其他市场中也不多见。

发布新应用的审核比较慢,估计是后台人工测试比较仔细。后续新版本的添加和更新想对来讲会比较顺畅。

同时,原先后台似乎并不支持 IE 外的浏览器(害得我还得开虚拟机),但近期测试似乎都没问题了。

小米开发者站

审核想对比较严格,严格的程度甚至你需要调整你的应用文案(例如不能有太多的空格,相对比较短的段落等)。在小米市场中重复拒绝和提交是很常见的事情,这点建议您需要有心里准备。

同时,小米市场会对审核不通过的应用有具体的说明和指导。有次提交新版应用有崩溃的情况,市场更是直接提供了 logcat 日志文件,细节做得很到位。

运营商市场

尝试过联通、移动以及电信天翼的应用市场,但普遍这些市场交互以及功能方面有先天的缺陷。有些市场只支持 IE 浏览器,同时需要提交的认证信息会极大的考验你的耐心和自制力。

在统计数据看来相对其他「民营」的应用市场,下载量比较少。除非有必要以及需要特定的渠道,个人非常不建议在此类市场上登记发布应用。

品牌商市场

尝试过 HTC、Samsung、以及 Moto 市场。

在这些市场中均没有得到很好的体验,甚至在 Samsung 市场中我无法通过正常的注册流程。 因此,个人和公司出于时间和成本考虑,放弃了这些市场。

其他

国内还有大大小小的其他 Android 应用市场,如果有遗漏的相对比较大型的市场欢迎您提出。

总结

现在发布 Android 应用到各大市场是个工作量非常巨大的事情。所以我们需要根据实际情况和用户群发布,这里主要给出我个人的看法:

第一批队

第二批队

第三批队

第四批队

如果你不想在发布方面占用太多的事情,建议保证第一、第二批队的市场版本更新完全即可。选择市场本身还需要根据自身以及应用的多种情况判断。

同时,应用内部本身需要做好良好的版本更新提醒,这会更少程度减少用户安装和更新应用的成本。

-- EOF --

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHub (2) 、 TwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,作为码农知道取名是件很难的事情。最后想到的这个名字,其实都没啥特别的含义,系统默认的文件名而已。

作为八零后,自认为还仅存点傲娇式的幽默感,以及对平淡生活的追求和向往。 为了免得对号入座和不必要的麻烦,声明本站点所持观点仅代表个人意见,不代表自己所服务公司的立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

文章

项目