2021年ICSE中与Android相关的论文分享

关于2021 ICSE
- 文章1：Too Quiet in the Library: An Empirical Study of Security Updates in Android Apps’ Native Code
- 文章2：RAICC: Revealing Atypical Inter-Component Communication in Android Apps
- 文章3：ATVHUNTER: Reliable V ersion Detection of Third-Party Libraries for Vulnerability Identification in Android Applications
- 文章4：IMGDroid: Detecting Image Loading Defects in Android Applications
- 文章5：Fine with “1234”? An Analysis of SMS One-Time Password Randomness in Android Apps
- 文章6：App’s Auto-Login Function Security Testing via Android OS-Level Virtualization

关于2021 ICSE

ICSE全称是the International Conference on Software Engineering，是软工方面的高水平会议，2021年ICSE于5月20日-30日召开。本文分享了今年ICSE中与Android相关的6篇论文，涵盖了第三方库（TPL）、组件间通信（ICC）、图像处理、OTP（one time password）和克隆攻击等内容，这里小结了每篇论文中用到的关键技术和实验结果，并对每篇文章进行了一定的小结。

文章1：Too Quiet in the Library: An Empirical Study of Security Updates in Android Apps’ Native Code

作者：Sumaya Almanee, ArdaÜnal, Mathias Payer, and Joshua Garcia
论文概要：
Android应用往往会调用第三方native库来提高代码性能和重用性，因此第三方native库中的代码在各个APP中都会执行。第三方native库的作者和APP开发者有着不同的更新周期，通常当第三方库出现了安全漏洞时，作者往往能在比较短的时间内打上安全补丁，而普通的APP开发者因为各种原因通常不会及时地更新这些库甚至忽略了第三方库的更新，这必然会留下安全隐患。本文作者针对2013年9月至2020年5月Google Play上的最受欢迎的200个免费应用的数千个版本进行了分析，创建了一个专门用于分析APP中使用的第三方库的库名、版本信息的工具LibRARIAN。使用此工具，本文作者得出了市面上大多数APP开发者更新第三方库不及时的结论，其中某些APP使用的第三方库目前仍易受一些CVE漏洞的攻击，APP开发者往往需要第三方库作者十倍的时间来进行这些库的更新，这无疑给用户带了巨大的安全隐患。

关键技术：LibRARIAN(LibRAry veRsion IdentificAtioN)工具
这个工具实现的功能是给定一个二进制文件，它能表示出文件属于的库和对应的库版本。
工具本质上是一款二进制文件比较工具，利用一些特性和已知的第三方库信息进行对比得出判断结论。
原理图：

提取特征可以分为5个元数据和1个数据项，分别为导入/导出全局变量、导入/导出函数、库依赖、文件中的特征字符串。选取这些特征的原因是这些特征已经能很好的区分二进制文件的库信息了，同时这些信息不受编译环境和平台的影响。在比较过程中用到的核心比较方法还是正则式匹配和关键字符串比较，通过一个本文作者自己提出的度量方法bin2sim，即算出两个二进制文件（一个为已知的库文件）的特征交集数量和特征并集数量的比值，超过一定的阈值（0.85）即认为二者相同。如果bin2sim不奏效或者有多个候选结果就直接去.rodata中匹配库的版本标识符和版本字符串，运用一定的启发式方法，命中则得出结果。

实验部分：
本文提取了Google Play中的top200 APP的7678个版本，这200个APP中有145个使用了第三方Native库，共有5852个版本，其中包括了总共66684个.so文件，平均每个应用程序有11个库，Instagram使用第三方Native库最多，以下是结论

在准确率上与工具OSSPolice比提高了12%，同时和OSSPolice比本工具不依赖源码；
LibRARIAN成功识别了46个库904个版本中的824个，准确率达91.15%；
37.42%的二进制文件可以使用版本标识字符串进行推断，45.29%的二进制文件可以使用元数据特征进行推断，17.29%的二进制文件可以使用两种特征类型进行推断。导出函数和导入函数占元数据特征有效性的绝大多数，分别占58.25%和32.98%；
有53个APP在2013年9月至2020年5月期间存在过有漏洞的库被利用的危险，其中有14个APP仍包含有存在漏洞的库，这些APP更新已经过时了859.17 ± 137.55天；
OpenCV和GIFLib库影响了大量APP，因此很多知名APP也存在多种漏洞，这些APP拥有庞大的用户群体，因此这些漏洞威胁很大；
库作者平均在漏洞发现后54.59 ± 8.12天打上安全补丁，但APP开发者要用上528.71 ±40.20天来用上这些补丁；
APP开发者往往需要数年的时间来更新库版本，安全隐患巨大；
被忽视的APP更新延迟从588.5天到5年不等，有必要加快更新速度；
未来应该重视这些易被忽视的库更新，并且确保更新中不会引入新的错误。

本文的核心观点可以概括为：当第三方库出现了漏洞时，库作者往往会警觉到问题的严重性并及时采取补救措施，而采用这些库的APP开发者往往会忽略一些本身的安全问题，为了方便、省事或其他原因（频繁的更新会降低用户的使用体验）而选择很久才更新一次（更新可能是希望使用新的功能而不是因为库打上了一些漏洞补丁），这个时间差给了攻击者利用的机会。所以说漏洞被曝出后，即使相关作者进行了及时修复但由于使用者的不重视可能会导致漏洞仍然存在很长一段时间，这当中无疑是存在安全隐患的，APP开发人员应该更加重视第三方库的及时更新。

文章2：RAICC: Revealing Atypical Inter-Component Communication in Android Apps

作者：Jordan Samhi, Alexandre Bartel, Tegawendé F. Bissyandé and Jacques Klein
论文概要：
组件间通信（Inter-Component Communication，ICC）是Android系统的关键机制。它使开发人员能够组合丰富的功能，并探索应用程序内部和跨应用程序的重用。ICC相当复杂导致静态分析跟踪ICC十分困难，现有的静态分析方法（如EPICC、ICCTA和AMANDROID）对于非典型的ICC分析无能为力，本文作者定义了这种非典型的ICC，并构造了一个工具RAICC来将apk进行预处理，处理后的apk中含有代码插桩的内容，插桩的部分就是传统方法没有顾及到的非典型ICC（文中成为AICC）的部分，这样处理后的apk再交由上述静态分析工具去分析能够得到更全面的ICC分析数据。

关键技术：
首先区分ICC和AICC，这里的A是指Atypical，相较于一般的ICC，AICC被定义为能进行组件间通信但不是其主要目的方法，这些方法依赖于PendingIntents和IntentSenders，它们是对已有的Intent的封装，但它不是立刻执行某个行为，而是满足某些条件或触发某些事件后才执行指定的行为。执行中它们将授予接受应用与源应用相同的权限和标识，它们由Android系统维护，及时原来的APP程序被杀死，PendingIntents仍可以使用。IntentSenders被封装到PendingIntents中，可以通过getIntentSender（）方法使用它，二者使用方式相似。这里ICC与AICC的主要区别可以通过下图看出来

图中token代表PendingIntents和IntentSenders，action代表AICC方法的主要目的（如发送SMS），action可能影响token list，从而导致发送Intent，虚线代表action可能触发的结果。开发人员使用AICC这种技术的主要原因就是为了在APP进程被杀死后仍然能触发一些功能，但与此同时AICC在Intent中携带了信息，可能会导致敏感数据泄露等问题。
本文作者分析了Android源码，通过字符串查找等方式找出了所有AICC的方法，共有111种。紧接着作者设计了一款RAICC的工具来增强ICC分析的解析程度。RAICC设计思路如图

对应的五步分别为：1.将APK转化为Jimple；2.推断目标组件类型，添加尽可能多的新的标准ICC方法，对PendingIntent的目标类型进行划分；3.恢复创建PendingIntent的原始Intent，RAICCA在程序间搜寻Intent；4.代码插桩，RAICC将AICC修改为明显的ICC方法；5.打包后生成新的APK

实验部分：
本文作者针对近5年在Androzoo上的50000个良性和50000恶性应用进行了不同类别的多次测试，得出了以下结论

AICC方法在Android应用程序中使用很普遍，值得关注。它们在恶意和良性应用程序中都有使用，但恶意开发人员的使用率明显更高。只有一小部分AICC方法被经常使用。
AICC方法在Android框架中并不新鲜，它们确实从一开始就存在并在每个版本都有所更新
RAICC提高了目前最好的数据泄漏检测器（ICCTA和Amandroid）的精确度和召回率
RAICC显著增加了其他分析器对实际应用程序解析出的ICC链接的数量。虽然AICC方法似乎不会用于泄漏敏感信息，但它们可以用于激活组件（从而可能触发恶意有效负载）。RAICC通过发现新的ICC漏洞使EPICC分析效果更好。
RAICC的运行时性能高于IC3和ICCTA，但仍处于同一数量级。平均而言，RAICC需要不到2分钟的时间来分析和测试应用程序。

这篇文章提出了不同于传统ICC的AICC方法，构建工具对AICC进行“改造”后再进入传统的ICC分析环节，这样进行一步预处理的好处自然是能发现更多的ICC，对静态分析而言会更加全面，虽然RAICC本身会引入不小的开销，但对于检测而言无疑更全面意味着更好的检测结果

文章3：ATVHUNTER: Reliable V ersion Detection of Third-Party Libraries for Vulnerability Identification in Android Applications

作者：Xian Zhan, Lingling Fan, Sen Chen, Feng Wu, Tianming Liu, Xiapu Luo, Yang Liu
论文概要：
本文研究的重点是对目前Android第三方库（TPL）和使用这些库的APP的安全性调查，设计了一个名为ATVHUNTER的系统，该系统可以精确定位应用程序中的TPL 版本的漏洞和TPL的详细信息，这个系统本身采用了一种两阶段的方法检测TPL，同时本文作者进行了大量的实验，构架了一个全面的已知易受攻击的TPL数据库，该系统拥有很高的精确率和召回率，该系统可以发现APP中易受攻击的TPL，对提升APP的质量有所帮助。

关键技术：ATVHUNTER
它以Android应用程序为输入，根据构建的数据库自动识别APP所使用的易受攻击的TPL，大体上可分为两部分：：（1）识别应用程序使用的特定版本的TPL；（2）易受攻击的TPL-V识别，这里易受攻击参考了NVD[34]和Github[35]上收集到的已知漏洞。该系统的设计图如下，分为以下几个步骤：

TPL检测：包括程序预处理阶段（将APP反编译为合适的中间表示，然后删除APP开发人员写的模块以减少对TPL判断的影响）；模块解耦阶段（将APP的模块拆分为不同的独立库候选模块）；特征生成阶段（两种粒度结合使用，粗粒度提取CFG，细粒度从提取CFG中每个基本快的操作码作为特征以进行精确的版本识别），这个阶段同时从Maven爬下了所有JAVA TPL来构建TPL数据库；库识别阶段（识别APP中使用的存在漏洞的TPL，一是潜在的TPL识别，即按Class来识别，二是TPL版本识别，在版本识别时用了编辑距离的阈值和方法的数量阈值）
存在漏洞的TPL确认：包括构建数据库阶段（搜集已知的有漏洞的TPL，用了cvesearch，同时与工业界合作获得了大量安全漏洞）；判断是否为有漏洞的TPL（识别APP中的TPL并与数据库匹配并生成漏洞报告）
实现：使用python编写，使用apktool反编译APP，使用Androguard获得class依赖关系，使用soot生成CFG，使用ssdeep执行模糊哈希来生成代码特征，使用编辑距离算法来查找APP中的TPL

实验部分：
准备阶段：建立数据库（验证ATVHUNTER的有效性；与其他类似工具比较；向社区发布数据集）；阈值选择；实验设置（从精确率，召回率和F1分数进行评估）

有效性：ATVHUNTER优于最先进的TPL检测工具，在库级实现了98.58%的准确率和88.79%的召回率，在版本级实现了90.55%的准确率和87.16%的召回率。
效率评估：与其他工具相比，ATVHUNTER能够高效准确地识别TPL，并且在真实TPL数据库中进行TPL检测所需时间短。
抗代码混淆能力：选择了100个APP并用工具Dasho进行模糊处理，得到一组原始应用和四组混淆过的应用，在此基础上进行比较，ATVHUNTER提供了比现有工具更好的代码模糊恢复能力，特别是对于标识符重命名、包扁平化和控制流随机化
针对Google Play的大规模研究：大约12.37%的APP包含了易受攻击的TPL等，对TPL开发者而言要修补的东西很多，对APP开发者而言大多不重视此类问题，对应用市场而言缺乏这样的评估机制

ATVHUNTER工具本身还有JAVA代码版本等问题的限制，同时它也是一种静态分析的方法，但是对目前的Android生态调查的结果来看TPL方面的结果不容乐观，与前面第一篇论文相比，前文侧重在native层的TPL，同时侧重在APP分析和时间线研究，而本文是更广义的TPL检测，二者都提出了第三方库对Android生态的影响，第三方库确实在给开发者带来便利的同时引入了许多安全问题，可以进一步进行研究。

文章4：IMGDroid: Detecting Image Loading Defects in Android Applications

作者：Wei Song, Mengqi Han, Jeff Huang

论文概要：
本文的关注点在Android APP的图像处理方面，图像处理是绝大多数APP都有的功能，应用程序开发人员可以使用Android原生SDK或第三方图像框架在应用程序中加载和显示图片。然而，由于图像通常非常大，如果加载或处理不当，应用程序的性能和质量可能会严重下降。图像处理和加载本身存在五种缺陷，即通过Intent传递图像、图像不重新适应大小就解码、没有权限时加载本地图像、无缓存的重复解码、在UI线程中解码图像。为了对这五种反模式进行研究，本位构造了一个静态分析工具IMGDroid，该工具能够有效的检测这些反模式并检测已知和未知的图像加载缺陷，同时调查了大量APP发现图像加载缺陷普遍存在。

关键技术：IMGDROID
补充：Android APP中的图像显示流程：

IMGDROID的主要任务是将输入的APP转化为CFG和调用图，然后根据支配关系分析、可达性分析、污点分析和依赖分析的结果，利用了工具Soot和FlowDroid，输出APP图像加载过程中的缺陷，如下图所示

其中支配关系分析和控制依赖分析的一些定义如下
CFG中节点的关系：
支配者：如果所有从入口到n的路径都经过n1，则n1是n的支配者
后支配者：如果所有从n到出口的路径都经过n2，则n2是n的后支配者
控制依赖：如果c到n有路径，n是路径中的所有其他点的后支配者，但不是c的后支配者，则n控制依赖于c
针对5种反模式的检测方法：

检测通过Intent传递图像：Intent传大量数据会影响性能，检测方法很简单，检查intent.putExtra(‘‘key’’, value)或bundle.putParcelable(‘‘key’’, value)中的valve，如果是Bitmap, Drawable或BitmapDrawable就是检测到
检测不调整大小的图像解码：小屏上的大图会产生负面影响，检测只考虑来自网络和SD卡的外部图片，因为资源图像是开发者已知的。对Android原生API和框架，检测是否存在调整大小的参数和代码语句，对于第三方框架检测后支配关系，如果解码后总有调整大小则正常，否则有缺陷
检测没有权限的本地图像加载：读取本地图像前应检查权限，否则APP可能会出发异常或崩溃。检测分为三步，一是检查是否有读取本地图像操纵，有则进入步骤二；二是查看Manifest是否声明所需权限，没有则进入步骤三；三是检查图像解码语句是否控制依赖于获得读取外部存储器权限的语句，没有则发现一个缺陷
检测无缓存的重复解码：使用缓存能解决视图频繁切换的问题，当组件的回调函数中有图片加载时如果没有缓存则图像会被反复解码，导致GUI滞后。检测同样分为两种，对于Android原生API检查CFG中图像解码没有进行缓存的后支配者，则有缺陷；对于一些框架，如果解码声明中没有参数则认为没有缓存；使用ImageView.setImageURI()必遭重复解码
检测UI线程中的图像解码：在UI线程中加载图片会降低APP性能，甚至出现ANR，对Android原生API和Picasso检查后台线程是否调用图像解码，如果有调用链能回溯到UI事件则认为存在缺陷。

实验部分：

有效性和效率：IMGDroid在2424秒内成功地检测到了21个应用中所有的45个已知缺陷，另外还发现了15个手动确认的未知缺陷，具有有效性和健壮性、完整性。
1000个商业应用的实证研究：897个（89.7%）涉及图像解码和显示操作。图像加载API广泛应用于Android应用程序中。在图像框架中，Android原生API是最常用的，而Fresco很少使用。865个存在共5471个图像加载缺陷。
显性图像加载缺陷：1000个应用中反模式1-5的缺陷数（比例）分别为178（3.25%）、2678（48.95%）、147（2.69%）、310（5.67%）和2158（39.44%）。
图像加载缺陷分布：使用Android原生API涉及图像加载缺陷的可能性最高，而使用Universal-Image-Loader涉及图像加载缺陷的可能性最低

本文讨论的图像加载对APP的影响，问题本身涉及的是APP运行时的自身安全性和稳定性，而非恶意行为或者漏洞等，因而描述的是目前存在的“缺陷”，本文的研究内容对APP开发者而言进行代码优化和提升用户体验有一定的帮助。

文章5：Fine with “1234”? An Analysis of SMS One-Time Password Randomness in Android Apps

作者：Siqi Ma, Juanru Li, Hyoungshick Kim, Elisa Bertino, Surya Nepal, Diethelm Ostry, and Cong Sun
论文概要：
本文讨论了目前在APP中应用广泛的一次性密码（OTP）技术的安全性，目前市面上绝大多数需要登录的Android APP都支持使用OTP作为登录凭证，OTP能确保安全性的前提是其不可预测性，但伪随机数生成器（PRNG）的不当实现将导致可预测的甚至静态的OTP值，使它们容易受到潜在的攻击。本文为了评估这方面存在的问题构建了工具OTP Lint，自动化的评估PRNG的实现，利用逆向找到SMS OTP触发方式并测试OTP值，在没有服务端源码的情况下评估PRNG。实验结果表明6431个APP中有399个是易受攻击的，并且其中194仅适用OTP验证身份，证明了目前APP的OTP存在缺陷。

关键技术：
常用的伪随机数生成算法包括：线性同余生成器（LCG）、滞后斐波那契生成器（LFib）、马特赛特旋转演算法（MT）、长周期线性均匀分布（WELL）等。
常用的随机数函数包括：C/C++中的rand()和rand_s()、Python中的random.randrange(start, stop)和numpy.random.rand(d0, d1, . . . , dn)、PHP中的lcg value()，rand(min, max)和mt rand()、JAVA中的random()，Math.random()和SecureRandom()等
本文提出了OTP应该遵循的3条大规则，违反规则即可认为是存在缺陷的：

不要使用静态OTP值
不要根据特定模式生成OTP值，可以细分为不要生成OTP值的重复序列、不要将每个不同的OTP值重复n次和不要使用可预测的二进制表示生成OTP值
不要使用常量或可预测种子来初始化随机函数
实现过程中的几个主要挑战就是服务端随机算法的未知性、收集OTP的数量大小（对实验有效并不影响服务器的正常使用）
OTP-LINT的设计图如下所示，由三个大部分组成，即认证定位、请求处理和漏洞检测

认证定位环节做了五件事情：候选创建者生成候选样本；应用程序代码分析器分析目标应用程序的代码并提取依赖项；输入生成器创建测试Activity；登录定位器标识真实环境中Android应用程序的登录活动；当应用程序中没有标识登录Activity时，反馈处理程序会优化测试Activity
请求处理环节使用SMS OTP身份验证方案处理APP，首先得到所有实现了SMS OTP授权的APP，然后在root过的机器上实验，提取OTP
漏洞检测环节依照前文中的三条规则来判断OTP的合理性

实验部分：共6431个不同的实验样本，1000个来自Google Play，5431个来自Tencent MyApp，OTP-Lint成功分析了4015个APP，失败的部分是因为OTP-Lint无法反编译或分析这些APP，分析成功的部分中有3657个APP涉及到了登录的Activity，2022个使用SMS OTP，最后违反规则的结果总结如下，同时发现Google Play和Tencent MyApp两个平台具有差异性、最易受攻击的前三类分别是视频播放/编辑器、娱乐、音乐/音频APP。

本文对目前大量使用的Android中的OTP技术进行了安全性调研，核心问题是研究目前市面上APP的OTP口令生成是否合理，满足安全需求，结果也发现了部分APP的OTP并没有采用合理的生成机制，导致这些APP的OTP存在可预测性，因而可能会导致用户受损，对于APP开发人员来说是值得注意的一个方面，有一定的警醒作用。

文章6：App’s Auto-Login Function Security Testing via Android OS-Level Virtualization

作者：Wenna Song, Jiang Ming, Lin Jiang, Han Yan, Yi Xiang, Yuan Chen, Jianming Fu, Guojun Peng

论文概要：
由于手机这种移动设备本身的特点，目前大多数APP在设备上都是一次登录后不需要再重复登录，登录凭证会一直有效。对于这种方便用户的策略存在着数据克隆攻击，即将受害者手机中的本地数据（包括保存自动登录信息的数据）全部克隆出来，则有可能直接获取受害者登录状态的APP，目前针对这种克隆攻击也有APP采取了设备指纹识别等额外验证过程。本文开发了VPDroid，一个透明的Android系统级别的虚拟化平台，专门用于安全测试，VPDroid可以定制虚拟环境中的各种硬软件，有效的隔离了虚拟环境中用户模式下APP对真正设备的检测，VPDroid可以欺骗所有执行设备一致性检查的测试应用，本文也证明了仅在客户端强制执行设备一致性检查仍然容易受到高级数据克隆攻击。

关键技术：
对于普通的数据克隆攻击，目前主流的Android APP都有一定的应对措施，例如微信能检测22中设备足迹，直接进行克隆攻击将无法造成威胁。
目前许多OEM厂商有自带的换机功能等，厂商本身拥有得天独厚的优势，但即便如此仍有APP需要重新登录。
Cells是第一个在单个Android实例上运行多个独立虚拟手机的轻量级操作系统级虚拟化解决方案，但其本身已过时，缺乏对很多新功能的支持。
设备一致性检查是导致最多克隆攻击失败的直接原因。
VPDroid虚拟化架构图，VPDroid基于Cell升级改进。

VPDroid的设计满足了两个需求：VP能直接访问设备硬件，提供和真机几乎同等的性能；VP中用户态下的APP对设备环境不敏感，VP的设备属性定制对这些APP不可见
VPDroid保留了Cell的输入和传感器功能，重新定义了大部分模块并加入了蓝牙、GPS和ADB等。
VPDroid定制设备属性的工作流程如下，目前能支持101个设备选型定制

实验部分:

一个视频例子demo
先对234个热门应用进行克隆攻击测试，分别使用真实设备、基于Xposed的沙盒和VPDroid执行数据克隆攻击时的成功次数，结果如下

VPDroid本身开销很小，与在真机上运行没有明显差异

克隆攻击本身是一个很早就有的方法，对此各大厂商都制定了不同的防御对策，其中最主要的就是搜集设备的指纹信息，分析APP所处的环境，本文作者独特的提出了定制化虚拟设备的方案VPDroid，似的基本的设备指纹检测方案变的不再可行，是一种高效使用的攻击模型，同时合理利用的这款工具，也能为安全人员制定合理的防御措施提供了测试环境，是一项很有意义的工作。

2021-05-28 2021年ICSE中与Android相关的论文分享相关推荐

【离散数学】 SEU - 24 - 2021/05/28 - Algebraic System
Discrete Mathematical Structures (6th Edition) 2021/05/28 - Algebraic System Algebraic System Binary ...
【每周CV论文推荐】 CV领域中数据增强相关的论文推荐
欢迎来到<每周CV论文推荐>.在这个专栏里,还是本着有三AI一贯的原则,专注于让大家能够系统性完成学习,所以我们推荐的文章也必定是同一主题的. 数据增强在每一个深度学习项目中都是必要的操作 ...
Java 网络编程学习复习总结（一）-2021.05.28
网络编程什么是计算机网络? 计算机网络是指将地理位置不同的具有独立功能的多台计算机及其外部设备,通过通信线路连接起来,在网络操作系统,网络管理软件及网络通信协议的管理和协调下,实现资源共享和信息传递 ...
光流 | 特征光流之视频中物体检测一（论文分享）
===================================================== github:https://github.com/MichaelBeechan CSDN: ...
2021.05.15继承球体和圆柱体
原文链接: 自动车手动车:https://codeeggs.github.io/2021/05/15/2021.05.15%E7%BB%A7%E6%89%BF%E7%90%83%E4%BD%93%E ...
前端面经笔记 2021.8.28
前端面经笔记 2021.8.28 下面哪些执行结果为true() A.'foo' == new function(){ return String('foo'); }; B.'foo' == new ...
市面上主流编辑器介绍（2021/05/20）
市面上主流编辑器介绍(2021/05/20) 背景 Markdown是一种有用的轻量级标记语言,后续Markdown简写为md. 富文本编辑器(Rich Text Editor,RTE)是一种可内嵌于 ...
DS SIMULIA CST STUDIO SUITE 2021.05 SP5
CST Studio Suite 2021.05 - 发行说明此补丁是推荐更新,其中包括以下更正和改进. 许可 CST Studio Suite Frontend 包括 CST Studio Sui ...
2021.05.05青蛙过河
2021.05.05青蛙过河 (题目来源:https://leetcode-cn.com/problems/frog-jump/) 题目描述一只青蛙想要过河. 假定河流被等分为若干个单元格,并且在每 ...

2021-05-28 2021年ICSE中与Android相关的论文分享