#Python #Data #recommended #coolapk
https://github.com/unnamed5719/coolapk-users

酷安爬虫大数据，已停更

https://github.com/by-syk/CoolapkUserStats

同

#Android #Kotlin #Coolapk
https://github.com/ruixingchen/CoolApkTokenComputer

不知道这个生成算法是否有效

应该有效，不过

我发现它其实是通过尝试设置系统时间『欺骗』原生代码来解决生成令牌有效期的问题...
（打住，不是，它修改的是程序环境内部的时间，目的是获得指定时间点的 UUID，然后交给 liba.so!getAS(char *uuid)
生成算法依然是酷安的，只不过是我们多次调整 UUID 时间计算了一打留用而已。

计算结果是一大堆 Token，各自有记录自己的有效期（5 分钟一个）

和原来的生成算法无关...
不过也算是体验了一下 Kotlin Common，不虚此行...

至于算法我可以再逆向

我测试重写的： #Android #Coolapk #Java #Kotlin #JavaScript

/* Common */
package coolhack

expect object Helper {
fun parseDateUnix(fmt: String): Long
}

data class Token(val unixTime: Long, val uuidText: String, val token: String)

object Generator {
fun generate(uuid: String, beginValidUnix: Long, expiresAtUnix: Long): Token {
TODO()
}

fun generate(uuid: String, beginDateFmt: String, endDateFmt: String): Token {
return generate(uuid, Helper.parseDateUnix(beginDateFmt), Helper.parseDateUnix(endDateFmt))
}
}

/* JavaScript */
package coolhack
import kotlin.js.Date

actual object Helper {
actual fun parseDateUnix(fmt: String): Long = Date.parse(fmt).toLong()
}

/* JVM */

package coolhack

import java.text.SimpleDateFormat

actual object Helper {
actual fun parseDateUnix(fmt: String): Long = SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse(fmt).time
}

原来的算法和理念分析： #reveng

https://github.com/ruixingchen/CoolApkTokenComputer#principle

这个项目是从 by-syk 的直接 GUI TokenGetter 派生的
作者表示他研究了这些算法，但是没有成功
Token 是和系统时间以及 UUID 直接相关的，在原生代码里做了一些诸如字符串倒序的算法操作
作者表示自己不擅长阅读汇编，也不知道他们如何根据这两个输入变量生成访问令牌

虽然无法知道算法细节，但可以修改系统时间『欺骗』原生代码，从而为还没达到的『未来』生成一打有效令牌
即使每个令牌只能『活』300 秒（300sec / 60spm = 5min），288（24hpd * 60mph / 5mtks = 288tks）个令牌也能足够『活』一天了


最核心的代码是列表批量生成算法和分段计算 Token

https://github.com/ruixingchen/CoolApkTokenComputer/blob/master/app/src/main/java/com/by_syk/coolapktokengetter/MainActivity.kt#L49
分段计算算法

算法流程组合和数学计算比较多，太复杂就不讲了，这里说一下那个分段计算的注释是怎么回事

generateToken() take 一 UUID（计算中不会发生改变） 一 startTime 一 endTime
然后它会让 getAS() 函数不断生成 600s 的 Token 直到生成的 Token 有效期覆盖到 endTime（currentTimeUTC <= endTimeUTC; currentTimeUTC += 290，少的 10 秒是为了交换的网络延时）之后的 300 秒『一个周期』为止

而所谓的分段计算就是把这个逻辑的使用分到以 7L*24L*60L*60L （一个星期的时间单位）为标准
因为出于某些原因其实此算法不能是并行的 — 副作用太强大了 — 严重依赖系统时间的生成算法会被影响

其实我觉得到底能不能提升效率 10 倍... 不知道啊，因为实际上就是把同样的工作量，一个分 10 步做 一个分 一步又分 10 步做，该设置系统时间的调用还是无法避免...

https://github.com/ruixingchen/CoolApkTokenComputer/blob/master/app/src/main/java/com/by_syk/coolapktokengetter/MainActivity.kt#L150
批量列表生成算法

出于工程量考虑，这次逆向将使用 RetDec 辅助完成.
感谢 Avast! 大大的好东西。
（要不然我手动看汇编不知道要看多久呢...

看 RISC 架构的汇编可丝毫不比 CISC 架构的简单一分，反而可能更加困难
正如 RISC 架构的编译器也更难设计...

附上滑稽一只

##Moha #Haha #School #life 🐸 全部生命续给江主席！（暴力）

事前，我在 Radare2 里 ia 了一下看看最新的 liba 和老的 liba 有什么区别，就 size 来比较其实没有多大区别

新的 liba 多使用了一个 strcmp 函数
getAS JNI 导出也比之前的体积 1303 增加到了 1988

链接多链了一个 liblog，之前的是 libstdc++、libc、libm、libdl

iE 导出其他的没有多大变化

逻辑上的确有区别，不知道现在服务器认哪个，反正我弄最新的那一个

这次他们的确做了包名检验，不过，我目前还是逆向新手... 暂时没有特别的能力看出执行时实际的东西，但是逻辑我都大致看得出来

RetDec 效果远远没有那么好，只能减小工作量，比之前强的是现在能通过编译了...

收了一个 Lua 32 位版本用来测试是否正确实现算法逻辑，不必要的逻辑诸如签名校验和包名校验都去掉

gcc -c liba.so.c -D__asm_rep_movsd_memcpy=memcpy -fPIC
ld liba.so.o -lc -shared -o liba.so

f = package.loadlib('./a.out', 'BEL')
f(0)
Segmentation fault
不错。不错。

其实 RetDec 分析出 C 语言的结果还不如 radare2 的清晰... 真的
Radare2 使你可以自底向上地重写出程序，而目前阶段 RD 的准确度只能用于辅助分析而已... 连方法签名分析好都难呢...

#Lua #build #sysadmin

刚才我编译 32 位的 Lua（为了测试正确性）

有 multilib 的话直接给 CFLAGS 和 LDFLAGS 加上 -m32 即可
可是说 ld 找不到 -lreadline...
我临时的解决方案是不使用 -lreadline，找到 relocable 后手动添加 file /usr/lib/libreadline.so.7.0

编译成功

要还原的（新的 DLL）

https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot #Sysadmin 正在准备新的 Alpine #Linux X86 Chroot 容器....

LD_LIBRARY_PATH=`pwd`/alpine-minirootfs-3.8.1-x86/usr/lib:`pwd`/alpine-minirootfs-3.8.1-x86/lib /lib/ld-linux.so.2 ./alpine-minirootfs-3.8.1-x86/usr/bin/lua5.1

我居然用上了容器里的 Lua5.1...

...因为的确已经熬了一夜了，而且这些的确是首先以学习为主...
（主要还是想让程序能运行起来... 成天和 linker、relocatable、shared object、静态链接动态链接杠... 我真的不想熬夜啊...
我决定再重新逆向 BEL 函数，成功了就睡觉...唉

非常失败，我根本不知道为什么要先 mov eax, [ebp + 8] 再 mov ecx, [eax + 2]，这种看起来根本对不齐一个字的操作到底有什么意义...

#sysadmin #Assembly #reveng #failure #life

算是体验了一下 NASM 和 x86_64 交叉 x86，此外，没有别的。