duangsuse::Echo
🤔 接下来 duangsuse 给大家做一瞬生成的现场的表演（良心） #sysadmin #Ruby #Parser #recommended 首先，按照上面的消息把 Retrofit 接口定义的 Java 代码整成这个 Parser 可以理解的格式 然后，执行命令 ruby simple_parser.rb retrofit.java 1>result.json，导出成果到 JSON 文件 ary = File.read('result.json').yield_self(&JSON.method(:parse))…
以上脚本只能部分自动化（而且 Spectrum 目前也没有兼容 MutliBody 的 API，因为 GeekApk 没有用到），要使用的话还是得自己修补一下才行...
不过也可以减小工作量了。
不过也可以减小工作量了。
This media is not supported in your browser
VIEW IN TELEGRAM
等到我写完 Spec 文件并且解决 API 客户端的兼容问题、下一步就该讨论怎么破解酷安的『官方』客户端口令验证保护，让它能在 Ruby Spectrum 的环境下可用
完全用 Ruby 还原校验码生成算法，这很困难（因为编译优化），我之前试过逆向一点小逻辑，都花了很长时间 #reveng
不过，x86 是个很通用的平台，我觉得可以拿 radare 修改汇编代码、对象文件属性给它 port 到一个相对宽泛一点的平台，然后每次用的时候直接用 v86.js 这样的虚拟机器执行，反正桌面端基本都是 x86，Android 端不是有 Token generator 么。
困难在于，如果类似的虚拟机比较『底层』，不是我想的那样只是基于宿主环境，作为一个『翻译』工具而工作，而是在没有操作系统支持的情况下工作，就会很困难。
还有个问题是，很多机器是 x86_64 的，和 x86 不完全兼容，当然有了虚拟机这个或许可以无视
完全用 Ruby 还原校验码生成算法，这很困难（因为编译优化），我之前试过逆向一点小逻辑，都花了很长时间 #reveng
不过，x86 是个很通用的平台，我觉得可以拿 radare 修改汇编代码、对象文件属性给它 port 到一个相对宽泛一点的平台，然后每次用的时候直接用 v86.js 这样的虚拟机器执行，反正桌面端基本都是 x86，Android 端不是有 Token generator 么。
困难在于，如果类似的虚拟机比较『底层』，不是我想的那样只是基于宿主环境，作为一个『翻译』工具而工作，而是在没有操作系统支持的情况下工作，就会很困难。
还有个问题是，很多机器是 x86_64 的，和 x86 不完全兼容，当然有了虚拟机这个或许可以无视
HackingCoolApk_1.zip
39.3 KB
写了一点，API 太多了（
🤔学术的时代结束了？（暴论）（ #baidu 我就记得有一个百度学术... 正准备喷百毒没社会责任感不如 Google 呢）
Forwarded from duangsuse Throws
Forwarded from dnaugsuz
PHP（
F#、Haskell、Scala、Scheme、Clojure 什么的吹抽象思维能力和对编程语言的理解（当然还有递归、算法数据结构、集合论、图论...）
C#、Java、Kotlin、Swift、Obj-c 吹各种清奇的设计模式和 OO 风格，以及对实际应用编程的描述能力（复杂度封装）
Python、Ruby、JavaScript 吹一大堆各种社区库、数据处理语法便利和元编程（Python dalao，对 Matlab、Octave、Woflram 也是一样）
C、C++、D、Go、Rust 吹底层编程机器相关属性访问度和高性能高并发，计算机网络有时候也看这种
各种鄙视链好像都还没有 PHP 的份（可能 PHP 要靠语法上的奇特，比比较 UNIX-like 的 Ruby 和 Python 给人感觉还 UNIX 2333）
PHP 是杂交的，但是我感觉 PHP 的程序员很多时候没有啥可以吹的（
可能是 PHP 写的应用都不需要多秀吧（跑 🤔
每次看到隔壁 Android 开发，一大堆 XXXFragment XXXManager XXXProvider XXXAdaptor XXXResolver XXXService ViewHolder RecyclerView AIDL 各种设计模式类继承、计算机图形学画画 sin cos acos 就不明觉历。
比起 Qt，Android 开发这设计模式可谓艺术....
F#、Haskell、Scala、Scheme、Clojure 什么的吹抽象思维能力和对编程语言的理解（当然还有递归、算法数据结构、集合论、图论...）
C#、Java、Kotlin、Swift、Obj-c 吹各种清奇的设计模式和 OO 风格，以及对实际应用编程的描述能力（复杂度封装）
Python、Ruby、JavaScript 吹一大堆各种社区库、数据处理语法便利和元编程（Python dalao，对 Matlab、Octave、Woflram 也是一样）
C、C++、D、Go、Rust 吹底层编程机器相关属性访问度和高性能高并发，计算机网络有时候也看这种
各种鄙视链好像都还没有 PHP 的份（可能 PHP 要靠语法上的奇特，比比较 UNIX-like 的 Ruby 和 Python 给人感觉还 UNIX 2333）
PHP 是杂交的，但是我感觉 PHP 的程序员很多时候没有啥可以吹的（
可能是 PHP 写的应用都不需要多秀吧（跑 🤔
每次看到隔壁 Android 开发，一大堆 XXXFragment XXXManager XXXProvider XXXAdaptor XXXResolver XXXService ViewHolder RecyclerView AIDL 各种设计模式类继承、计算机图形学画画 sin cos acos 就不明觉历。
比起 Qt，Android 开发这设计模式可谓艺术....
Forwarded from dnaugsuz
所谓运行期类型，因为 Java 8 有反射特性么，就可以理解为一个
Java 的 Object 类的 Class <?> getClass() 方法，所有正常的 Java 对象都可以拿到它的
这涉及到 OOP 的多态什么的... 反正我也弄不懂就是了（
比如说我们有一个静态方法
🤔 其实我应该用泛型的... 要不然编译期类型和运行期类型的区别也不好显现，算了，我说多了（抱歉）
而所谓的 Kotlin smart cast 呢，就是（代码片段）：
Object 的 Class<T> 🤔Java 的 Object 类的 Class <?> getClass() 方法，所有正常的 Java 对象都可以拿到它的
Class<T>，我值的运行期类型是这个这涉及到 OOP 的多态什么的... 反正我也弄不懂就是了（
比如说我们有一个静态方法
Foo.printMessage，所谓静态方法呢就是一个类而不是它的对象所拥有的行为，因为 Java 不是 Ruby 那种内建高等 Inspect 特性的语言，所以类是类对象是对象，当然也有历史的原因 :(class Foo {
static PrintStream out = System.out;
static void printMessage(CharSequence msg) {
Foo.out.println(msg);
Foo.out.println(msg.getClass().getCanonicalName());
}
static void main(String... argv) { Foo.printMessage(String.valueOf("Hello")); }
}
对于 printMessage 的第一个参数（无论对于 Java 语言层面还是 Java 的字节码层面都是第一个参数，因为它是静态方法）来说，所谓编译期类型就是 CharSequencemain 里面对它的调用，运行期类型就是 String（CharSequence 的一个子类型，虽然 CharSequence 实际上是一个接口，但在不同层面/方向看它就会有不同的结果，可以 javap java.lang.CharSequence 检查一下 CharSequence 的源码）🤔 其实我应该用泛型的... 要不然编译期类型和运行期类型的区别也不好显现，算了，我说多了（抱歉）
而所谓的 Kotlin smart cast 呢，就是（代码片段）：
final Object obj = (Object) String.valueOf("");
if (obj instanceof String) {
String message = /* 这个是不必要的强制转换，因为执行到这里已经能说明 obj 是个 string */ (String) obj;
}
Kotlin 编译器可以根据控制流分析自动推导出在这个分支里 obj 肯定是个 String，所以 (String) obj 这种 Boilerplate code 就可以不写。Forwarded from Yuuta 🎀 | clrd enroute
Kotlin 写 data 是真的舒服（
Forwarded from 湘江一桥
直接用java写相对要小巧一些或者说是兼容更好？
Forwarded from dnaugsuz
Kotlin + Proguard / R8 也是很小的，你 Disable Kotlin Reflect 用 Kotlin JVM 的 Reflect 就可以
Forwarded from dnaugsuz
小体积的原则就是尽可能自己写（
比如 parser，很多时候自己写 recursive descent method 的 parser 都会比 Bison/Flex Style 的高大上 LL(1) LALR 算法（比如说，Java 里的 Jay、Cup、Beaver 甚至 JavaCC 这些 Parser generator） Parser 小很多。
而且又优雅。
比如 parser，很多时候自己写 recursive descent method 的 parser 都会比 Bison/Flex Style 的高大上 LL(1) LALR 算法（比如说，Java 里的 Jay、Cup、Beaver 甚至 JavaCC 这些 Parser generator） Parser 小很多。
而且又优雅。
Forwarded from 羽毛的小白板
其实这是我做的第二个小工具。第一个是好几年前做的，就单纯专门接收 GCM 然后发个通知。之后就没碰了。而且那时候是用家里的老爷机弄，开个 AS 就卡到爆炸了😶
是手机上 AIDE 开发的，那时候不知道什么设计模式，就是单纯的模式识别抄代码（我甚至抄到了 KK 沉浸状态栏的代码，利用一个四边形的彩色 View... 还有一个渐变动画 bling bling 效果的代码），花了一周左右，能用是从完全不懂 Jawa 开始四天后。
然后我发上了酷安 #coolapk 那时候酷安才 v6
现在我在逆向工程破解酷安 v9 的客户端验证令牌生成算法 🤔
希望能成功，如果成功了那对于桌面平台，酷安 API 的『官方』客户端限制就彻底爆破喽
顺便写自己的酷安 — GeekApk
顺便写 GeekSpec，想要弄个可以优雅 Handle 所有 HTTP API 的工具
顺便写了个编写递归下降法 Parser 的工具
偶尔用 Ruby 写工具，喜欢 Kotlin
然后我发上了酷安 #coolapk 那时候酷安才 v6
现在我在逆向工程破解酷安 v9 的客户端验证令牌生成算法 🤔
希望能成功，如果成功了那对于桌面平台，酷安 API 的『官方』客户端限制就彻底爆破喽
顺便写自己的酷安 — GeekApk
顺便写 GeekSpec，想要弄个可以优雅 Handle 所有 HTTP API 的工具
顺便写了个编写递归下降法 Parser 的工具
偶尔用 Ruby 写工具，喜欢 Kotlin
（先熟悉一下分析环境，CoolApk 的 API Spec 待会再写） #reveng #GeekApk #CoolAPK #PL
Spectrum 我觉得非常需要重构，我会给 DSL 制定新的语法规范，因为实际使用中，我能看到很多东西并不是开始我设计 DSL 的时候想的那样... DSL 目前有点太混沌了，新的 GeekSpec 1.0 将能兼容 GeekApk v1b 和 CoolApk v6 两款实际应用的 API，一样简洁富有表现力的语法，但会有更清晰的描述语义和更多的特性（比如返回状态 matching)。
所以 CoolApk 的 SPEC 文件我还是要写，但暂时不打算重构 Spectrum 来支持 CoolApk 的新 API 特性，暂时可以用一些 Workaround 方案支持某些 API，感谢 Ruby 的灵活吧（迫真）
====
新的酷安 liba.so 没有很大区别，编译的时候少加了一个不需要的
看起来，不过，虽然好像业务代码没有用 C++ 异常，还是依赖了
我拿到的 liba.so 是 liba 的 x86 版本，因为比起 ARM 我更熟悉 x86，而且 CISC 机器一般更好分析
这个版本是从 coolapk.com 拿到的官方版本，酷安 v8
== 它包含这些动态链接依赖：
它依赖以下外部函数：memcpy / memset / strlen / sprintf / strcmp / time / strcat
还有这些无关算法本身的依赖：__cxa_finalize / __cxa_atexit / __stack_chk_fail / __stack_chk_guard
它的导出符号：BD / BDL / BE / BEL / MI / MU / MF / r / bd / me / be / Java_com_coolapk_market_util_AuthUtils_getAS
JNI 使用的只有 Java_com_coolapk_market_util_AuthUtils_getAS 这个符号
我逆向重写过的只有 BEL 这个函数，它的定义如下（C）：
我觉得运行时替换掉这些函数，添加 log 参数和返回值的代码可能有助于分析算法
编译时采用了 stack guard 反溢出机制
Spectrum 我觉得非常需要重构，我会给 DSL 制定新的语法规范，因为实际使用中，我能看到很多东西并不是开始我设计 DSL 的时候想的那样... DSL 目前有点太混沌了，新的 GeekSpec 1.0 将能兼容 GeekApk v1b 和 CoolApk v6 两款实际应用的 API，一样简洁富有表现力的语法，但会有更清晰的描述语义和更多的特性（比如返回状态 matching)。
所以 CoolApk 的 SPEC 文件我还是要写，但暂时不打算重构 Spectrum 来支持 CoolApk 的新 API 特性，暂时可以用一些 Workaround 方案支持某些 API，感谢 Ruby 的灵活吧（迫真）
====
新的酷安 liba.so 没有很大区别，编译的时候少加了一个不需要的
liblog.so 依赖（实际上它不（向 logd）打印任何 log，这是无用的依赖，但当时我比现在菜所以移除这个依赖甚至对我来说比较难...）看起来，不过，虽然好像业务代码没有用 C++ 异常，还是依赖了
__cxa_finialize （好吧这点是我弄错了，那不是 landingpad personality 函数（迫真））我拿到的 liba.so 是 liba 的 x86 版本，因为比起 ARM 我更熟悉 x86，而且 CISC 机器一般更好分析
这个版本是从 coolapk.com 拿到的官方版本，酷安 v8
com.coolapk.market, platformBuildVersionName="8.8.3", versionCode = 0x1ba289, usesSdk: [0x15..0x1c]
（信息使用 ~/Android/Sdk/build-tools/28.0.3/aapt dump xmltree f81b5d8361e1e197cd336a443710532e-0-o_1crp2etomvdkhmr1kfq1ghh18c6-uid-408649.apk AndroidManifest.xml 获得）== 它包含这些动态链接依赖：
它依赖以下外部函数：memcpy / memset / strlen / sprintf / strcmp / time / strcat
还有这些无关算法本身的依赖：__cxa_finalize / __cxa_atexit / __stack_chk_fail / __stack_chk_guard
它的导出符号：BD / BDL / BE / BEL / MI / MU / MF / r / bd / me / be / Java_com_coolapk_market_util_AuthUtils_getAS
JNI 使用的只有 Java_com_coolapk_market_util_AuthUtils_getAS 这个符号
我逆向重写过的只有 BEL 这个函数，它的定义如下（C）：
int BEL(int n) { return (4 * (n - 1) / 3 | 3) + 2; }
借助逆向分析 CoolApk X-App-Token 生成算法的机会，我也顺便学习了一些 X86 汇编的知识。我觉得运行时替换掉这些函数，添加 log 参数和返回值的代码可能有助于分析算法
编译时采用了 stack guard 反溢出机制
Telegram
duangsuse::Echo
探索出了能用的公式，实现了 liba.so!BEL （int BEL(int n)）
duangsuse::Echo
（先熟悉一下分析环境，CoolApk 的 API Spec 待会再写） #reveng #GeekApk #CoolAPK #PL Spectrum 我觉得非常需要重构，我会给 DSL 制定新的语法规范，因为实际使用中，我能看到很多东西并不是开始我设计 DSL 的时候想的那样... DSL 目前有点太混沌了，新的 GeekSpec 1.0 将能兼容 GeekApk v1b 和 CoolApk v6 两款实际应用的 API，一样简洁富有表现力的语法，但会有更清晰的描述语义和更多的特性（比如返回状态 matching)。…
从某种意义上来说，第三方要想做『酷安客户端』，真正的困难仅仅在于
X-App-Token，其他都是体力活，他们的接口用 Retrofit 都可以直接绑定上（实际上他们就是用 OkHttp+Retrofit）。（又是 Observable (Stream) 设计模式 hhh）