Fix crash on Android 11 #133

kotori2 · 2020-11-21T16:28:59Z

Fix #132 #130 (probably)
鉴于某谜语壬宁愿在issue里面讲故事也不发PR，那我自己研究下好了
Since someone figured out but won't send a PR, I'll do it.

From the crash trace, it tries to call artQuickGenericJniTrampoline and art_quick_generic_jni_trampoline, which will read data_ from ArtMethod instead of entry_point_from_quick_compiled_code_, which will get null pointer and it won't properly throw a Exception. But according to the Changelog, it might cause hook fail on Android O+, but it seems working for me with even debug build.

Credits: @yujincheng08

yujincheng08 · 2020-11-22T13:16:15Z

@lianglixin 你也是谜语人：有更好的解决方法。
所以方法呢？

ghost · 2020-11-22T13:20:42Z

@lianglixin 你也是谜语人：有更好的解决方法。
所以方法呢？

💴

yujincheng08 · 2020-11-22T13:26:12Z

@lianglixin 在人家开源项目底下说钱，真有你的呢

canyie · 2020-11-22T13:55:42Z

@yujincheng08 把ClassLinker::ShouldUseInterpreterEntrypoint 这个函数inline hook掉，对于被hook过的方法让其返回false就能解决debug不生效的问题；另，yahfa作者明确表示过不想再引入一套完整的native inline hook框架，所以我没发pr。

yujincheng08 · 2020-11-22T13:56:52Z

@canyie 这个其实edxp有个接口只是没实现。我个人不是很喜欢这种native hook的方法。

kotori2 · 2020-11-22T19:46:34Z

@yujincheng08 把ClassLinker::ShouldUseInterpreterEntrypoint 这个函数inline hook掉，对于被hook过的方法让其返回false就能解决debug不生效的问题；另，yahfa作者明确表示过不想再引入一套完整的native inline hook框架，所以我没发pr。

看起来我遇到的并不是这个问题；我试了下直接拿yahfa的示例app在debug build的系统跑是没问题的，但是edxp在hook了这个函数后，甚至没有遇到过被hook的method检查ShouldUseInterpreterEntrypoint，不过楼上用模拟器测试的时候并没有遇到这个问题。

rk700 · 2020-11-23T01:11:43Z

谢谢 @kotori2 @yujincheng08

aviraxp · 2020-11-22T03:54:03Z

library/src/main/jni/HookMain.c

        if (SDKVersion >= __ANDROID_API_Q__) {
            // On API 29 whether to use the fast path or not is cached in the ART method structure
            access_flags &= ~kAccFastInterpreterToInterpreterInvoke;
+        } else {


这个是不是把Q漏了

shuajinanhai · 2020-11-23T13:16:41Z

某谜语壬测试下来，发现有个问题，不知道是谜语壬的问题，还是你的问题，、会调到java层的backup里。
public static Toast backup(Context context, CharSequence text, int duration) {
try{
Log.e("yahfa", "this is cannot delete, come in is error!!!");
return null;
}catch (Exception e){
return null;
}
}

2020-09-26 19:29:34.779 9988-9988/lab.galaxy.yahfa E/yahfa: this is cannot delete, come in is error!!!

rk700 · 2020-11-25T03:20:41Z

hook的目标target方法原本的入口是什么？backup的trampoline会最终调用target原本的入口（如果是要解析的话可能就会根据native access flag错误解析到jni？）

shuajinanhai · 2020-11-25T05:07:39Z

2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: replace entry point from 0x791f808fa0 to 0x7bb37b93a0 2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: change access flags from 0x12080009 to 0x12080009 2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: replace method from 0x71233098 to 0x790472a1d8 2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: replace entry point from 0x791f808fa0 to 0x7bb37b93c0 2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: change access flags from 0x12080001 to 0x12080001        这里是 access_flags &= ~kAccFastInterpreterToInterpreterInvoke; 但执行前后access_flags是一样 2020-09-28 11:28:25.546 28866-28866/lab.galaxy.yahfa.demoApp I/YAHFA-Native: hook and backup done 2020-09-28 11:28:25.641 28866-28866/lab.galaxy.yahfa.demoApp E/origin: call Log.e()        这里永远都是调用原函数，不会进hook函数大佬还是亲测一下吧

…

------------------ 原始邮件 ------------------ 发件人: "Ruikai Liu"<notifications@github.com>; 发送时间: 2020年11月25日(星期三) 中午11:20 收件人: "PAGalaxyLab/YAHFA"<YAHFA@noreply.github.com>; 抄送: "1281579248"<1281579248@qq.com>; "Comment"<comment@noreply.github.com>; 主题: Re: [PAGalaxyLab/YAHFA] Fix crash on Android 11 (#133) hook的目标target方法原本的入口是什么？backup的trampoline会最终调用target原本的入口（如果是要解析的话可能就会根据native access flag错误解析到jni？） — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

kotori2 · 2020-11-25T05:55:32Z

@rk700 没记错的话是backup解析成了JNI。的确我这边用edxposed的话会因为没有quick_code所以走解释，但是用YAHFA应用是有quick_code的，可能是跟系统是debug build有关系。

shuajinanhai · 2020-11-25T07:06:18Z

我这里debug或者release都是一样的情况。好吧，那我也说下自己的解决方案吧，我使用了Handler.sendMessageAtFrontOfQueue完美修复11.0闪退问题（完美不闪退，包括一加8），但是这样会导致hook时机会偏慢一点点，后面我开了一个线程去等待，可以解决时机问题，但是现在在一加8，上会发现部分游戏有崩溃现象，也是那个队列的问题（但是是因为这个线程引起的）。另外建议作者可以测试时候直接在hook完马上调用dowork(),不要放在button里去测试。这样即使测试正常，真正使用还是会发现有很多问题

…

------------------ 原始邮件 ------------------ 发件人: "双草酸酯"<notifications@github.com>; 发送时间: 2020年11月25日(星期三) 中午1:55 收件人: "PAGalaxyLab/YAHFA"<YAHFA@noreply.github.com>; 抄送: "1281579248"<1281579248@qq.com>; "Comment"<comment@noreply.github.com>; 主题: Re: [PAGalaxyLab/YAHFA] Fix crash on Android 11 (#133) @rk700 没记错的话是backup解析成了JNI。的确我这边用edxposed的话会因为没有quick_code所以走解释，但是用YAHFA应用是有quick_code的，可能是跟系统是debug build有关系。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

shuajinanhai · 2020-11-25T07:10:35Z

跟native这个flag没关系，而且R系统也是必须加这个flag。

rk700 · 2020-11-25T09:13:49Z

native flag记得是很早之前引入的，主要为了防止hook不生效

现在好像是backup添加native flag，解析会变成jni stub？这几个方法的原本entry都是什么？R我只有模拟器显示几个方法的entry都是interp bridge，所以没有复现出来jni的情况

shuajinanhai · 2020-11-25T10:02:18Z

R系统在AS上的模拟器是正常的，并且以前做反射在AS上的模拟器都不需要pass,，所以作者，不要在模拟器上测试，会浪费时间还得不到准确答案。

shuajinanhai · 2020-11-25T10:05:57Z

Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 14181 (.bigbull.tdsgtw), pid 14181 (.bigbull.tdsgtw)，我是觉得跟队列有关系，SI_QUEUE，所以我用我的方案是成功修复，不会闪退，只是一个时机问题。开一个线程等待就可以解决，然而跟libil2cpp会有冲突，需要attach（domain）那个

rk700 · 2020-11-25T10:16:34Z

没有R真机

#130 的trace里面，确实有art_quick_generic_jni_trampoline，这个是有问题，不知道是怎么根据native flag解析到jni trampoline的

kotori2 · 2020-11-25T10:21:41Z

https://cs.android.com/android/platform/superproject/+/master:art/runtime/class_linker.cc;l=3742;drc=master;bpv=1;bpt=1
没有quick_code的情况下就走到jni了

shuajinanhai · 2020-11-25T10:24:09Z

可以参考下sandhook这个
void* getInterpreterBridge(bool isNative) {
SandHook::ElfImg libart(art_lib_path);
if (isNative) {
return reinterpret_cast<void *>(libart.getSymbAddress("art_quick_generic_jni_trampoline"));
} else {
return reinterpret_cast<void *>(libart.getSymbAddress("art_quick_to_interpreter_bridge"));
}
}

rk700 · 2020-11-25T11:43:52Z

是在link阶段，应该不影响后面的运行时吧。这里的检查

https://cs.android.com/android/platform/superproject/+/master:art/runtime/class_linker.cc;l=3727;drc=master

ghost · 2020-11-25T12:09:43Z

是在link阶段，应该不影响后面的运行时吧。这里的检查

https://cs.android.com/android/platform/superproject/+/master:art/runtime/class_linker.cc;l=3727;drc=master

我提交的更改已经提示比较明显了，其实并不是所属什么Native Flag问题。Debug下实际表现跟安卓10之前一样，问题实际在GC，目前不通过钩子无法较好解决这个问题。具体在ArtMethod的invoke函数里面，走到执行分支，进入汇编函数闪退。汇编函数检测异常，进入处理异常流程，根本原因是Moving GC。

ghost · 2020-11-25T12:15:51Z

是在link阶段，应该不影响后面的运行时吧。这里的检查

https://cs.android.com/android/platform/superproject/+/master:art/runtime/class_linker.cc;l=3727;drc=master

目前有个比较复杂的解决办法，在汇编shellcode处加入结构体成员信息恢复流程，每次调用都恢复backup的成员信息，但是这样做影响性能。另一个方案不支持某些函数，兼容性不好，实现更复杂，容易引起崩溃，其实是更改hook框架的全部成员属性。

kotori2 · 2020-11-25T12:20:50Z

是在link阶段，应该不影响后面的运行时吧。这里的检查
https://cs.android.com/android/platform/superproject/+/master:art/runtime/class_linker.cc;l=3727;drc=master

我提交的更改已经提示比较明显了，其实并不是所属什么Native Flag问题。Debug下实际表现跟安卓10之前一样，问题实际在GC，目前不通过钩子无法较好解决这个问题。具体在ArtMethod的invoke函数里面，走到执行分支，进入汇编函数闪退。汇编函数检测异常，进入处理异常流程，根本原因是Moving GC。

你提交的更改=检测到debug就直接崩掉

kotori2 · 2020-11-25T12:32:17Z

汇编函数检测异常，进入处理异常流程

你仔细看看看就会知道实际上他崩的原因是Check failed: exception != nullptr，他出错是在artQuickGenericJniTrampoline这个函数，直接called->GetEntryPointFromJni();返回了个nullptr，然后汇编认为他出错了才跳到异常处理的，实际上是Android的bug导致他返回nullptr的时候没有设置exception

kotori2 · 2020-11-25T12:59:13Z

#130 的trace里面，确实有art_quick_generic_jni_trampoline，这个是有问题，不知道是怎么根据native flag解析到jni trampoline的

确实，LinkCode发生得比hook早，我之前改AOSP打了下log，那个方法被LinkCode的时候的确是没有quick_code的，不过既然这么说的话当时这里应该是走interpreter的。
结果感觉像是SetEntryPointsToInterpreter的问题

kotori2 · 2020-11-25T18:20:58Z

好了查明白了

11-25 22:54:27.846  8638  8638 D EdXposed:   # 0: 0x792f048a08  edxp::captureBacktrace(void**, unsigned long)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 1: 0x792f0462d0  art::ClassLinker::ShouldUseInterpreterEntrypointReplace(void*, void const*)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 2: 0x7936c12098  art::ClassLinker::FixupStaticTrampolines(art::ObjPtr<art::mirror::Class>)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 3: 0x792f0461f0  art::ClassLinker::FixupStaticTrampolinesReplace(void*, void*)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 4: 0x7936c41a50  
11-25 22:54:27.846  8638  8638 D EdXposed:   # 5: 0x7936c2e7cc  art::ClassLinker::InitializeClass(art::Thread*, art::Handle<art::mirror::Class>, bool, bool)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 6: 0x7936c0ada8  art::ClassLinker::EnsureInitialized(art::Thread*, art::Handle<art::mirror::Class>, bool, bool)
11-25 22:54:27.846  8638  8638 D EdXposed:   # 7: 0x79370d5898  MterpNewInstance
11-25 22:54:27.846  8638  8638 D EdXposed:   # 8: 0x7936b7d214  
11-25 22:54:27.846  8638  8638 D EdXposed:   # 9: 0x79370cfa38  MterpInvokeDirect
11-25 22:54:27.846  8638  8638 D EdXposed:   #10: 0x7936b7f918  
11-25 22:54:27.846  8638  8638 D EdXposed:   #11: 0x79370cd3bc  MterpInvokeVirtual
11-25 22:54:27.846  8638  8638 D EdXposed:   #12: 0x7936b7f818  
11-25 22:54:27.846  8638  8638 D EdXposed:   #13: 0x7936d57c38  
11-25 22:54:27.846  8638  8638 D EdXposed:   #14: 0x79370bbe24  artQuickToInterpreterBridge
11-25 22:54:27.846  8638  8638 D EdXposed:   #15: 0x7936b8effc  
11-25 22:54:27.846  8638  8638 D EdXposed:   #16: 0x7936b857ec  
11-25 22:54:27.846  8638  8638 D EdXposed:   #17: 0x7936bfaa98  art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, ar

这里FixupStaticTrampolines说是会"Link the code of methods skipped by LinkCode."，实际上是把所有static方法都重新设置了一遍。不过不知道非static方法是怎么走的。

shuajinanhai · 2020-11-25T18:56:10Z

程序员都是这么晚睡的吗。头发都还好吗 ------------------ 原始邮件 ------------------ 发件人: "双草酸酯"<notifications@github.com> 发送时间: 2020年11月26日(星期四) 凌晨2:21 收件人: "PAGalaxyLab/YAHFA"<YAHFA@noreply.github.com>; 抄送: "shuajinanhai"<1281579248@qq.com>;"Comment"<comment@noreply.github.com>; 主题: Re: [PAGalaxyLab/YAHFA] Fix crash on Android 11 (#133)

kotori2 · 2020-12-18T08:04:09Z

@google-mirror 其实你连epic的备注也没看

    /**
     * the static method is lazy resolved, when not resolved, the entry point is a trampoline of
     * a bridge, we can not hook these entry. this method force the static method to be resolved.
     */

google-mirror · 2020-12-18T08:06:41Z

@google-mirror 其实你连epic的备注也没看

    /**
     * the static method is lazy resolved, when not resolved, the entry point is a trampoline of
     * a bridge, we can not hook these entry. this method force the static method to be resolved.
     */

是的, 我就看了这个issue, 我错了, 大佬

rk700 · 2020-12-18T09:47:51Z

GetOatQuickMethodHeader的那个问题，我看下来似乎是这里造成的？
https://cs.android.com/android/platform/superproject/+/master:art/runtime/art_method.cc;l=592

我们把 target 的 entry 替换成 hookTrampoline 了，从这个新的 entry 直接往前计算偏移得到 OatQuickMethodHeader
https://cs.android.com/android/platform/superproject/+/master:art/runtime/oat_quick_method_header.h;l=47;drc=master

这个所谓的OatQuickMethodHeader肯定是不对的，导致计算 Contains(pc) 出错

那么我们是否可以在 hookTrampoline 前构造一个假的 OatQuickMethodHeader？让其 code_size 为0，使得Contains(pc) 不会挂掉且返回 false，继续从原始的 oat file 获取真正的 entry 再计算 dexpc
https://cs.android.com/android/platform/superproject/+/master:art/runtime/art_method.cc;l=620

yujincheng08 · 2020-12-18T09:50:32Z

@rk700 我也是这个思路。在trampoline前面多放allocate一点空间，使得 OatQuickMethodHeader 指针正确并且能读出一个 0 的code_size。目前正在测试中

kotori2 · 2020-12-18T09:52:15Z

在trampoline前面多放allocate一点空间

其实可以构造一个mov r0, #0 这样的东西吧，不过我现在是直接偷懒把GetCodeSize给hook掉了

rk700 · 2020-12-18T09:54:35Z

在trampoline前面多放allocate一点空间

其实可以构造一个mov r0, #0 这样的东西吧，不过我现在是直接偷懒把GetCodeSize给hook掉了

mov r0, #0 是什么原理呢？

kotori2 · 2020-12-18T09:57:23Z

在trampoline前面多放allocate一点空间

其实可以构造一个mov r0, #0 这样的东西吧，不过我现在是直接偷懒把GetCodeSize给hook掉了

mov r0, #0 是什么原理呢？

我意思是，这样就可以在不炸掉程序的前提下获得几个字节的0，可以让GetCodeSize拿到0
Edit：是我理解错了，没注意到要-offset才是header

yujincheng08 · 2020-12-18T10:00:27Z

我觉得不如entrypoint前面多放几个0，这样还能保证 vmap_table_offset_ 是正确的，header的指针也正确

rk700 · 2020-12-18T10:03:13Z

嗯，感觉可以试下，好像前面就只有2个uint32，放8个0应该就可以？

yujincheng08 · 2020-12-18T10:04:09Z

@rk700 可以多放个，因为他还有 &~0x1

google-mirror · 2020-12-18T10:05:31Z

建议把整个class PACKED(4) OatQuickMethodHeader结构抄过来

yujincheng08 · 2020-12-18T10:07:01Z

@google-mirror 我就是这么做的。抄谷歌代码反算entrypoint的实际offset，保证最小的allocate

kotori2 · 2020-12-18T10:09:29Z

这个会有跨系统版本的问题，过两年你就要准备一大堆struct在代码里 Deleted user <notifications@github.com> 于 2020年12月18日周五 18:05写道：

…

建议把整个class PACKED(4) OatQuickMethodHeader结构抄过来 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#133 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGYNSNEGEY7M76IBAOMPLDSVMSPVANCNFSM4T54C2JA> .

yujincheng08 · 2020-12-18T10:10:18Z

其实我感觉放9个0，然后抄个 GetEntryPoint 拿到真正的entrypoint地址放trampoline就行。

google-mirror · 2020-12-18T10:21:25Z

首先, 我没细看, 只是抛个问题, 假设带上了字段, 返回了真正的OatQuickMethodHeader, 在DoGetCalleeSaveMethodCaller里可能会调用NativeQuickPcOffset(caller_pc), 不是照样崩溃么

yujincheng08 · 2020-12-18T10:34:58Z

@google-mirror current_code->IsOptimized() == false

google-mirror · 2020-12-18T10:38:09Z

@yujincheng08 current_code是真实的header, 不一定为false

yujincheng08 · 2020-12-18T10:55:15Z

@google-mirror current_code是我们自己造的

那么我们是否可以在 hookTrampoline 前构造一个假的 OatQuickMethodHeader？让其 code_size 为0，使得Contains(pc) 不会挂掉且返回 false，继续从原始的 oat file 获取真正的 entry 再计算 dexpc

google-mirror · 2020-12-18T11:36:39Z

@yujincheng08
current_code是GetOatQuickMethodHeader返回的, 意思是返回假的?
如果返回假的, 问题更多吧, 就拿DoGetCalleeSaveMethodCaller来说, 原本应该走GetResolvedMethod的逻辑就永远不走了

那么我们是否可以在 hookTrampoline 前构造一个假的 OatQuickMethodHeader？让其 code_size 为0，使得Contains(pc) 不会挂掉且返回 false，继续从原始的 oat file 获取真正的 entry 再计算 dexpc

按上面的说法, GetOatQuickMethodHeader返回的难道不是原始的header?

canyie · 2020-12-18T13:34:12Z

@google-mirror

  static OatQuickMethodHeader* FromCodePointer(const void* code_ptr) {
    uintptr_t code = reinterpret_cast<uintptr_t>(code_ptr);
    uintptr_t header = code - OFFSETOF_MEMBER(OatQuickMethodHeader, code_);
    return reinterpret_cast<OatQuickMethodHeader*>(header);
  }

kotori2 · 2020-12-19T10:08:09Z

其实又想了一下，即使把code_size正确设置了也没有什么用
这东西是为了在崩溃的时候找崩溃点的，如果崩溃点本身是被hook的函数的话，那么这里的code_已经是跳板了，在跳板所在区域搜索没有什么意义，那样依旧是不知道PC在不在原函数里。
然后会获得一个这样的崩溃：

Abort message: 'Check failed: found_virtual Didn't find oat method index for virtual method: java.lang.String[] android.icu.impl.ICUResourceBundle.getStringArray()'

Fix crash on Android 11 #133

Fix crash on Android 11 #133

Conversation

kotori2 commented Nov 21, 2020 • edited Loading

yujincheng08 commented Nov 22, 2020

ghost commented Nov 22, 2020

yujincheng08 commented Nov 22, 2020

canyie commented Nov 22, 2020

yujincheng08 commented Nov 22, 2020 • edited Loading

kotori2 commented Nov 22, 2020

rk700 commented Nov 23, 2020

aviraxp Nov 22, 2020

Choose a reason for hiding this comment

shuajinanhai commented Nov 23, 2020

rk700 commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020 via email

kotori2 commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020 via email

shuajinanhai commented Nov 25, 2020

rk700 commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020

rk700 commented Nov 25, 2020

kotori2 commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020

rk700 commented Nov 25, 2020

ghost commented Nov 25, 2020

ghost commented Nov 25, 2020

kotori2 commented Nov 25, 2020

kotori2 commented Nov 25, 2020 • edited Loading

kotori2 commented Nov 25, 2020 • edited Loading

kotori2 commented Nov 25, 2020

shuajinanhai commented Nov 25, 2020 via email

kotori2 commented Dec 18, 2020

google-mirror commented Dec 18, 2020

rk700 commented Dec 18, 2020

yujincheng08 commented Dec 18, 2020 • edited Loading

kotori2 commented Dec 18, 2020

rk700 commented Dec 18, 2020

kotori2 commented Dec 18, 2020 • edited Loading

yujincheng08 commented Dec 18, 2020

rk700 commented Dec 18, 2020

yujincheng08 commented Dec 18, 2020 • edited Loading

google-mirror commented Dec 18, 2020

yujincheng08 commented Dec 18, 2020

kotori2 commented Dec 18, 2020 via email

yujincheng08 commented Dec 18, 2020 • edited Loading

google-mirror commented Dec 18, 2020

yujincheng08 commented Dec 18, 2020

google-mirror commented Dec 18, 2020

yujincheng08 commented Dec 18, 2020

google-mirror commented Dec 18, 2020 • edited Loading

canyie commented Dec 18, 2020

kotori2 commented Dec 19, 2020

rk700 commented Dec 21, 2020

kotori2 commented Dec 21, 2020

rk700 commented Dec 21, 2020

yujincheng08 commented Dec 21, 2020

rk700 commented Dec 21, 2020

yujincheng08 commented Dec 21, 2020 • edited Loading

kotori2 commented Dec 21, 2020

zhoujunyou commented Oct 26, 2021

kotori2 commented Nov 21, 2020 •

edited

Loading

yujincheng08 commented Nov 22, 2020 •

edited

Loading

kotori2 commented Nov 25, 2020 •

edited

Loading

kotori2 commented Nov 25, 2020 •

edited

Loading

yujincheng08 commented Dec 18, 2020 •

edited

Loading

kotori2 commented Dec 18, 2020 •

edited

Loading

yujincheng08 commented Dec 18, 2020 •

edited

Loading

yujincheng08 commented Dec 18, 2020 •

edited

Loading

google-mirror commented Dec 18, 2020 •

edited

Loading

yujincheng08 commented Dec 21, 2020 •

edited

Loading