我打了三年的 ACM-ICPC 奥数比赛？？

弄了个测试 LaTeX 排版的，顺手又学习一下 TeX 方便以后发博文

字体的问题也真是纠结... 还好 \setmainfont 能给一个文档指定多个字体不至于遇上中文文字缺失的问题

#Learn #CS #PL #Math #TeX https://en.wikibooks.org/wiki/LaTeX

#Book #Fontend #GUI #Desktop 买了那本《Qt 5.9 C++ 开发指南》我才知道这种多『内部窗口』的被称为 MDI（多文档视口应用）

这次顺手买了一本 Qt、一本 C/算法数据结构计算机二级、一本嵌入式、一本操作系统的...

其中我觉得最有价值的目前是嵌入式，因为通过它我最终知道了很多汇编语言里 **h 这种语法是表示 C99 里的 0x** 十六进制数

并且领悟了 x86 的各种寄存器啊... 执行环境啊... 比如 AX AL AH 三寄存器有什么关系、MMU 是什么之类的
顺手悟出了 LR（系统栈链接寄存器）的用途（在 x86 里是 bp，栈指针是 sp，现在一般都算作通用寄存器，可惜即使这样都只有 8 个通用寄存器 GPR...）

这个是 XeTeX render 之后的成品，当然是有过程的，不过可以理解为是 compose 合成之后的然后就可以视作一个 operation 了，即使之前可能是先变成 dvi 文件再变成 p(ost)s(cript) 文件再变成 pdf...

DejaVu Sans ExtraLight 字体好看 :happy:

TeX 也是挺好用的，只要你只是单单拿一些既成的规则和指令组合做排版的话就不会特别困难，和 HTML 本质上就差不多

不过一些高级一点的用途自然还是花时间的，甚至可能烧脑，因为毕竟各种排版问题也是可以很困难很不容易解决

一般人拿来排版一下数学公式（当然，是对于喜欢更自由排版的人来说）就好了，有时候出一些书，然后自定义排版什么的可以再学或者找包，大概也不会花几天时间，反正写书是漫长的过程。

本来以为，这周至少能弄完那个 PixLisp 的测试版本和讲完关于面向过程和函数式可视化、位图/矩阵处理、FreeType、SIMD 优化什么的...

看来不大有时间，或许是打字慢了吧... 虽然我现在开始提升速度了 😐

以后这里的 #Telegram 长篇笔记都使用 XeLa #TeX 发布了。虽然开始还有点学习 curve 但我觉得还是有价值的，也训练了我以后做 $ \sout{枪手帮别人抄袭 papper 的能力} $

笔记都会使用 #Learn hashtag 标注，这是惯例（以之前几个长篇一点的都是）
届时欢迎大家随时观看笔记，等到到时候我有时间了就会开静态博客放上网去的（好耶

重新重写了一下，提高代码质量。 #Python #CG

#Tool #CG #Python #Project 最终版... 权当玩具... 可是貌似花了我一些时间调试和了解，其实 PIL 封装得也是... 有好有不好

#Sysadmin #Haha 升级版 emmm source ai.sh;ai 参考了实现论文（破真）

[DuangSUSE@duangsuse]~/Projects% ai             
㉄：我好郁闷啊
我也好郁闷啊 
㉄：我郁闷
我也郁闷 
㉄：真的？
真的! 
㉄：你也郁闷吗？
我也郁闷! 
㉄：hhh
hhh 
㉄：再见喽...
再见喽..

傻子...

5 个坏块，加起来大小一共有 500M 的样子

#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 架构的编译器也更难设计...