最近在搞 apk 爆破工程，经常需要调试别人的 apk，每次手动修改 apk 的 debuggable 属性比较麻烦，而且要有时候还不成功。所以还是一劳永逸，下载 AOSP ，把 ro.debuggable 打开，编一个 Nexus 5 的镜像给我手机用。关于 apk 调试的参考链接：https://www.0xaa55.com/technews/201602/00000215.html
下面是我在 windows 下，使用cygwin 下载官方 AOSP 时[……]
刚看到一句描述动态类型的话：“动态类型能够带来更高的灵活性——不需要接口或抽象类。”
这句话给我感觉是从一个动态类型语言（如Python）使用者的角度去说的，意思是我有了动态类型这种特性，我就不再需要先定好接口，然后实现类implement接口，才能调用指定的方法了。你只需要把对象给我，我直接调用，鸭子类型，非常方便。我“不需要”接口和抽象类。
而如果从一个Java使用者的角度去看动态类型，因为Java使用者总是习惯于使用接口和抽象类去约束代码，让代码在约定的框架内实现（我会很享受这种一切都在控制之中的感觉），所以面对动态类型时会有种失去“权力”的感觉：哎呀，如果这个类没有按照约定实现方法[……]
在做UAF的时候，我产生了一个需求：我希望我可以把demo，UAF Client，UAF ASM分别打包成3个apk，又可以打包成1个apk。当分别打包的时候，UAF Client/UAF ASM是application；统一打包的时候，UAF Client/UAF ASM是library。我开始进行尝试。
我希望在debug的时候，UAF Client/UAF ASM的build.gradle apply plugin: 'com.android.library'，release的时候[……]
最近在做UAF打包的事情，其中一个需求是根据debug/release和flavor来决定不同的依赖。比如debug情况下，我要打包带日志的，release情况下，我要打包带日志，不带日志，含其他module的，不含其他module的两两组合（也就是flavorDimensions）。现分享方法。
参考build.gradle：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
apply plugin: 'com.android.application' android { compileSdkVersion 25 buildToolsVersion "24.0.2" defaultConfig { applicationId "com.sickworm.test" minSdkVersion 10 targetSdkVersion 25 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), '../proguard-rules-remove-logs.pro' } // keep log and stacktrace preview { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } flavorDimensions 'log', 'combine' productFlavors { withoutLogs { dimension 'log' } withLogs { dimension 'log' proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } standalone { dimension 'combine' } mixed { dimension 'combine' } } } // This works because when we combine the flavor+build type into variant and create their associated // configuration objects, we only create them if they don't already exist. otherwise we reuse the ones that are created. configurations { withoutLogsMixedReleaseCompile withLogsMixedReleaseCompile } dependencies { compile fileTree(include: ['*.jar'], dir: 'libs') testCompile 'junit:junit:4.12' compile project(':clientapplication') debugCompile project(':asm') debugCompile project(':client') withoutLogsMixedReleaseCompile project(':asm') withLogsMixedReleaseCompile project(':asm') withoutLogsMixedReleaseCompile project(':client') withLogsMixedReleaseCompile project(':client') } |
大家都用过简单的debugCompile, releaseCompile。如[……]
实现UAF协议的时候，Client需要获取调用者的信息（获得其APK的签名）。用中文查了半天没查到获取Activity的方法，用英文一下就搜出来了（主要还是看英文累脑子）
Activity：
getCallingActivity()
getCallingPackage()
注意：
只有调用者使用的是startActivityForResult()，且Intent不设置NEW_TASK时才可以获取，调用startActivity()得到的是null。
Service：
Binder.getCallingUid()
Binder.getCallingPid()
注意：
当AIDL使用的[……]
今天发包给客户，发现混淆后的库时序有点问题。再三调试，发现锁失效了。wait()没有任何阻塞就跳过了。
ok，90%情况就是在哪里触发了notify/notifyAll咯。但找了很久，notify确实没有被调用。我就纳闷了。
最后我把我的库反编译出来看，发现我的锁的wait()语句被删了！源代码：EsLock.java
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
public void lock() { synchronized (this) { setLocked(true); try { Log.e("wtf", "" + 1); wait(); Log.e("wtf", "" + 2); } catch (Exception e) { e.printStackTrace(); LogUtil.w(TAG, e.getLocalizedMessage()); } setLocked(false); } } |
混淆后代码：
我翻了一下我CI上的库记录，发现前两个月的库是没问题的，看来是中间某段时间修改混淆脚本出了问题。
一番定位，找到了元凶：
|
1 2 3 4 |
-assumenosideeffects class com.excelsecu.driver.util.LogUtil { public *; } |
本文将介绍FIDO UAF各个文档的内容：
介绍了appID和facetID的命名规则和作用。
appID是app（可能是手机软件，也可能是网页）调用UAF Client时提供的标识名，而facetID是app中更具体的标识。
对于手机软件（Android和iOS），appID和facetID是一致的，Android的facetID必须是apk的签名信息，iOS的facetID必须app的bundle-id。
对于网页（可能是电脑，手机上的网页，或app内嵌的网页），FacetID就是一个URL，而appID必须和FacetID有相同的公共的[……]
FIDO联盟实施草案 2014年12月08日
本版本
https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-authnr-cmds-v1.0-ps-20141208.html
上一版本
https://fidoalliance.org/specs/fido-uaf-authnr-cmds-v1.0-rd-20141008.pdf
编辑：
Davit Baghdasaryan, Nok Nok Labs, Inc.
John Kemp,[……]
本文将介绍FIDO UAF的运作流程。
根据FIDO UAF文档介绍，FIDO UAF在移动设备上的实现将分为三层：Client，ASM，Authenticator。
当用户在App上进行操作时，App会先向Server发出请求，然后将Server返回的数据转发给Client。最后再将Client返回的结果转发给Server。Server最后回复操作结果。具体如下：
首先，App向FIDO Server发送GetUAFRequest，Server会返回ReturnUAFRequest，里面包含了与Client交互的数据。然后，App调用UAF Client并传入Server的数据执行注[……]
在FIDO UAF中一共有4种Authenticators（认证设备）：
* first-factor bound authenticator（第一因素绑定认证设备）
* second-factor bound authenticator（第二因素绑定认证设备）
* first-factor roaming authenticator（第一因素漫游认证设备）
* second-factor roaming authenticator（第二因素漫游认证设备）
其中，first-factor和second-factor的区别在于，first-factor authenticator会根据用户名存[……]