Tasker 永久试用修改思路

首先贴出官网链接以及 Google Play 商店链接。其实也不贵，当前价格 4.49 USD，强烈建议购买正版支持作者（使用外币信用卡即可）。由于我需要在无 Google Play 框架的机器上使用（无法通过验证），只得出此下策。

不知为何，目前网络上完全寻找不到破解版。甚至有很多所谓的“破解版”下载后校验签名就是官方签名，说明根本没有修改过。真搞笑。此应用有 7 天试用，未到期前没有任何提示。许多人借此机会，在各论坛发帖分享“破解版”，骗取回帖经验值。

目前最新版本为 6.6.20，但是，由于新版体积较大（包含了智能家居相关的 libCHIPController.so 等原生库），这里我们选择修改相对较旧的 6.1.32 版本。此版本 Target API 为 SDK 31 S，已经足够，且不包含任何原生库以及 Google Gemini 等无聊功能。我尝试过相同思路修改新版依然可以生效。

# 解开 apk
java -jar apktool.jar d origin.apk -o /tmp/apk_decoded -f
# 如果需要修改 6.6.20 且希望移除多余 so 原生库
rm -rf /tmp/apk_decoded/lib/armeabi-v7a /tmp/apk_decoded/lib/arm64-v8a/libCHIPController.so

试用机制分析（感谢 MiMo-V2.5 模型提供的支持）：

安装时间戳存储在 SharedPreferences，key 为 idt。
试用期计算在 Licence.smali 以及 Main.smali 中的检查。
逻辑：daysPassed = (currentTimeMillis - idt) / 86400000。
试用期硬编码为 7 天（const/4 v0, 0x7）。

所以最简单的思路就是试用期改大点，改到下辈子去。注意，不要暴力搜索 const/4 v0, 0x7！因为有很多常量都是 0x7 这个值，直接 grep 会爆炸。应当按照前面的原理分析，结合 0x5265c00（一天毫秒数）和比较逻辑来定位正确的修改点。

文件 smali_classes2/net/dinglisch/android/taskerm/Licence.smali，在 F0() 方法中找到：

    const/4 v5, 0x7

    .line 41
    iget-object v6, v0, Lnet/dinglisch/android/taskerm/Licence;->B:Landroid/content/SharedPreferences;

替换为：

    const v5, 0x7fffffff

    .line 41
    iget-object v6, v0, Lnet/dinglisch/android/taskerm/Licence;->B:Landroid/content/SharedPreferences;

文件 smali_classes2/net/dinglisch/android/taskerm/Main.smali，在约第 27070 行找到：

    .line 56
    const/4 v4, 0x7

    .line 57
    if-lt v0, v4, :cond_2

替换为：

    .line 56
    const v4, 0x7fffffff

    .line 57
    if-lt v0, v4, :cond_2

最后我们重新打包。压缩。签名。这里过程中还使用了 ect（优化过的 zopfli）。

java -jar apktool.jar build /tmp/apk_decoded -o raw.apk
aapt2 optimize -o optimized.apk --shorten-resource-paths --deduplicate-entry-values --enable-compact-entries raw.apk
rm -rf /tmp/apk_extreme /tmp/apk_extreme.zip /tmp/apk_extreme.zip
mkdir /tmp/apk_extreme
d=$(pwd)
pushd /tmp/apk_extreme
unzip $d/optimized.apk 2>&1 >/dev/null
mv resources.arsc ../
zip -1 -r -X $d/a.apk . 2>&1 >/dev/null
$d/zcodecs12 ect -9 --strict -zip $d/a.apk # extreme compress
mv ../resources.arsc .
zip -0 -X $d/a.apk resources.arsc # arsc as store
popd
zipalign -f -p 16 a.apk a.aligned.apk # 16k align
apksigner sign \
  --ks "password=123456.keystore" \
  --ks-pass pass:123456 \
  --key-pass pass:123456 \
  --ks-key-alias tasker-crack \
  --v1-signing-enabled true \
  --v2-signing-enabled true \
  a.aligned.apk
apksigner verify a.aligned.apk
# C:\Users\klc2u1\AppData\Local\Android\Sdk\build-tools\36.1.0\d8 classes.dex classes2.dex --min-api 21 --lib C:\Users\klc2u1\AppData\Local\Android\Sdk\platforms\android-35\android.jar --release --output .\dex_output\

使用 apktool（或 mt 管理器）解开 dex 到 smali 之后重新生成会增大体积，因此建议在验证可行性后，只编辑对应的 dex，避免触碰其他无关 dex。对于已被修改且体积膨胀的 dex，可以这样挽救一部分：

# 已经修改且打包过的 dex 文件，使用 baksmali 再一次反编译并安全剥离调试信息
java -jar baksmali.jar disassemble --debug-info false -o smali_out classes2.dex
# 不必多说
java -jar smali.jar assemble smali_out -o classes2_next.dex

不要尝试使用 facebook redex 来优化。对于这种没有调试信息的 dex 来说风险太大。很容易炸飞自己。