How You Get Shot in the Back: A Systematical Study about Cryptojacking in the Real World

•Introduction

加密劫持就是通过Web网页消耗客户端计算机上的计算资源来解决加密难题，从而为攻击者的挖矿提供额外的工作量，并且这种行为通常不会通知用户或者经过明确的用户同意。这种新机制就称为加密劫持。

加密劫持存在严重的滥用现象，如果要深入研究就得首先大规模识别此类加密网页。现有收集加密劫持样本的方法有两种：加密网页耗尽受害者的CPU资源，或者包含显式关键字的恶意有效载荷签名。但是作者发现了很多加密劫持其实是躲过了这两点检测的。例如，基于关键字的加密货币挖矿脚本搜索[28]可以通过简单的代码混淆技术来规避；攻击者也可以通过配置挖矿任务来保持CPU使用率在一定限度内。

然后作者提出了一种检测机制。它由两个基于运行时行为的分析器组成。第一个分析器，基于散列的分析器，利用了工作量证明系统的性质，该系统需要繁重的工作量来计算哈希值。因此，作者监视与哈希活动相关的脚本行为的统计信息。第二个分析器，基于堆栈结构的分析器，因为观察到加密货币的挖矿是重复和定期的，因此挖矿脚本的堆栈调用也必须是重复定期的。所以作者就通过记录运行时的堆栈来识别挖矿页面。

通过使用刚刚介绍的它们自己提出的这个检测机制的检测，最终从85万多个热门网页中收集了2770个加密劫持样本，其中包括在Alexa列表中前100K的有868个。Alexa是一家专门发布网站世界排名的一个网站。然后它们的检测结果中有53.9％的样本是现有的基于黑名单的检测器检测不出来的。并且它们的检测结果是2个月前（18年2月）360发布的最新公开报告的2.6倍。同时作者采用手动抽样检查的方式验证它们的检测机制检出来的结果是正确的（TP）。从而证明他们的检测机制在覆盖范围和精度方面都是不错的，优于现有的检测方法。

之后作者对他们检测出来的数据进行分析，并得到一些结论。从检测到的2,770个加密网站中，他们估计至少每月会影响到1千万的网络用户。进一步分析，他们发现每天加密劫持的工作量有超过278K千瓦时的额外的能源消耗，相当于一个拥有9.3K人口的小城镇的能源消耗。同时，估计攻击者每天的收入超过59K美元。

其次，他们通过研究加密劫持的基础设施发现恶意的角色是相互协作的。不同加密劫持样本的钱包ID很少有指向同一个攻击者的，所以存在大量不同的攻击者。此外，加密劫持页面会快速更改它的域，从而使现有的基于黑名单的解决方案无效。由作者实验可知，超过20％的加密劫持域持续不到9天，但黑名单平均每10至20天才更新一次。

然后它们发现至少有3种技术可用于规避当前已有可用的检测方法，包括限制CPU使用，挖矿脚本的代码混淆和有效载荷的隐藏。

这篇文章主要有三个贡献点：第一点，作者设计并实施了一个检测器，用于检测高精度和大覆盖范围的加密劫持。第二点，通过抓取并访问Alexa前100K的网站，以及每个网站里的几个链接，检测到了2,770个加密劫持页面。同时作者估计了加密劫持的一些影响，比如它每天的额外功率超过278K千瓦时，攻击者每天的收入至少为59K美元等。第三点，作者系统地研究了加密攻击的基础设施，分析了攻击域的各个方面和脚本的行为。

•Related Work

首先是加密劫持方面。经过用户反映，这种加密劫持的新现象正在增多，可能是由于加密货币的市场价值的提升所致的。Adguard [2]在2017年11月已经从Alexa排名前100K的名单中发现了220个加密网站。同时，Whorunscoinhive [33]显示了，使用Coinhive（最流行的加密货币挖掘脚本）的网站数量仅在一个月内增加了31.7％。

然后是加密货币安全方面。大多数现有的研究都集中在通过改进加密货币的设计和架构来构建更安全的生态系统。例如，Eleftherios等人[23]提出了一个新的拜占庭共识协议，他们的设计为比特币交易带来了更高的效率，同时又不牺牲其安全保障。

还一些工作重点是识别加密货币体系结构中的威胁和机会。Eyal等人[16]针对比特币挖矿提出了一种新型攻击方式。他们发现，合作可以让矿工获得比正常公平奖励得到的收入更多。Reid等人[30]研究了比特币系统的匿名性。他们发现，矿池可能会引发高代价的DDoS攻击，从而降低与其竞争的矿池的预期成功的前景。Johnson等人[15] 通过一系列不同大小的两个池之间的竞争博弈模型，探讨了这些策略之间的权衡。

最相关的工作是Plohmann等人[29]。他们研究了矿工僵尸网络的安全事件。但是，他们的研究并不在网络环境中。

之后是恶意JavaScript检测。因为作者对加密劫持的测量研究主要基于JavaScript代码分析技术。

现有的相关研究通常采用静态或动态分析来识别恶意JavaScript的特征。

首先动态分析，JS.JSAND [9]提取了四个不同方面的特征（重定向，反混淆，环境上下文和广告推销）。他们采用基于朴素贝叶斯的方法来检测JavaScript恶意软件样本，这些样本通过后台下载，自动在受害者机器上进行分发。

对于静态分析，Curtsinger等 [10]介绍了一种通过提取与程序的抽象语法树（AST）相关的功能来预测良性或恶意JavaScript代码的工具。

还有部分研究集中于通过利用一些独特的特征（如，广告商ID）来检测恶意广告脚本。Zarras等人 [37]研究了广告的安全性，以及用户如何暴露于恶意内容及其来源的。但是这些特征和加密货币挖矿的独特的特征还不太一样。

•加密劫持识别

第三部分从三方面描述了检测加密劫持网站的方法。首先，介绍了用于进行大规模研究的数据集。然后举例说明了两种基于行为的动态发现加密货币挖矿页面的方法。最后对这些自动识别的网站进行进一步的验证，以确定它们是否确实是加密劫持网站。

样本收集。他们整体的数据集还是比较大规模的真实世界的数据。他们关注的是最受欢迎的网站主页内部链接（包括子域）以及其直接外部链接。

最受欢迎的网站比较好理解，就是恶意挖矿页面倾向于通过那些经常访问的页面来最大化他们的利润。

主页的直接外部链接是指，比如一些恶意矿工不直接向排名靠前的页面注入恶意载荷，而是在这些顶级网站上有那种浮动宣传恶意页面的这种小广告，从而诱骗用户访问恶意页面。

然后作者抓取Alexa排名前100K的网站及其子域，随机访问了20％的内部或外部链接，也就是每个子域最多3个链接，例如google.com里访问maps.google.com和news.google.com两个子域。最终共收集了85万多个网页作为定位加密劫持网页的数据集。

图1描绘了作者定位加密劫持页面的整体流程。首先，他们通过刚刚说的收集方法得到他们测量研究所需的数据集。然后利用Chrome远程接口[11]通过堆栈取样记录并分析访问过的页面。之后通过利用两个基于行为的分析器来确定加密货币挖矿页面。最后，通过附加的验证步骤来排除那些良性的加密货币挖矿页面，比如明确告知用户挖矿或征求用户同意的这种页面，就是良性的。

作者的这个检测机制的重点就是两个基于行为的分析器。

首先基于哈希的分析器。因为我们知道挖矿的计算量主要是在哈希，而普通网站通常花费很少的时间来处理哈希函数。所以作者标注了9个常见的可访问的哈希库接口，然后计算这些数据集网站在哈希上累积花费的时间，从而识别网页是否正在挖矿。

图2 是前100个Alexa网站基于哈希工作量的比率累积分布图。横轴是哈希的时间占总执行时间的比率，纵轴是不超过某一工作量比率的网站在所有网站中占比多少。由图可知，前100个Alexa网站中的99％的网站哈希工作量的比率是低于0.47％的。所以作者规定，如果网页使用超过10％的执行时间进行哈希，那么分析器就会将其报告为在进行加密货币挖矿。

但是虽然基于哈希的分析器在识别大多数挖矿脚本时非常简单和精确，一些加密攻击者仍可使用代码混淆技术很容易地规避检测。所以作者又提出了基于堆栈结构的分析器作为互补检测器。

图4显示了普通网页很少重复相同的堆栈调用超过执行时间的5.60％。同时从图3作者发现了加密货币挖矿时堆栈显示出的重复的行为模式。图3是示例挖矿脚本的调用堆栈转换。可以看出，挖矿脚本的堆栈深度和调用链都是重复并且规则的。

之所以出现这种行为模式是因为，这种加密货币挖矿比较容易被用户注意到，所以大多数挖矿任务都不会在加载网页时的主线程上发生，而是创建一个或多个的专用线程。

因此，如果专用线程周期性地重复其调用链，并且调用链占用该线程中整个执行时间的30％以上，作者就将其报告为加密货币挖矿。

自动检测后还需要再验证一下。因为自动识别的结果不一定是恶意的，通常良性的网页会在用户协议下挖加密货币。所以作者提取已检测出的网页的所有文本内容，并基于一组预定义的关键字（例如，“挖矿协议”）检查是否为良性网页。虽然这个设置的有点粗，但是还是过滤掉了大多数良性网页。因为经过进一步分析可知，只有35个已识别的网页是良性的，其余的确实都是恶意的。

为了评估检测方法的有效性，作者随机选择已识别的加密劫持网站的子集，并进行进一步的手动验证过程。具体来说就是，检查200个网页，检查他们是否确实是在未经用户同意的情况下运行加密劫持脚本的。作者之所以不比对黑名单来进行评估，是因为已有的黑名单都是不完整（FN）和不准确的（FP）。所以他们的手动验证，最终表明所识别的网页都是正确的，没有误报。

•加密劫持脚本

作者针对2,770个已识别的加密劫持样本进行了分类，然后对这些加密劫持脚本在利润和能源消耗方面的影响进行了粗粒度的分析。

首先是加密劫持样本的整体分布。从表1中可以看出，在前100K 的Alexa网站中，作者的检测机制识别出了868个加密劫持域。还有1,902个是通过外部链接检测到的加密域，这1902个域是包含于前100K Alexa网站的44万多个不同域中的。总体他们识别了来自54万多个不同域的2,770个加密劫持样本。

然后作者把自己的结果与最新的公开报告做了比较，如表2所示。他们识别的加密劫持域的数量要比两个月前360.cn [1]的最新的公开报告多检测出了260%。然后360.cn的报告仅比四个月前第一行这个多检测了10％。所以作者得出的结论是，加密劫持案例的数量正在迅速增加。

之后作者对样本进行了分类，如表3所示，有近一半的恶意样本（49％）是艺术和娱乐以及成人网站。它们其中大多数是提供盗版资源的。之所以攻击者选择这种类型的web内容，是因为这些网站在搜索资源时是可能被长时间停留的，对用户有吸引力，可以带来更多的利润。

接下来作者用计算出的数据说明了一下网络上现有加密劫持脚本的严重性。

首先是通过加密货币挖矿获得的利润。他们用Coinhive 提供的公式来估算基于门罗币的利润。Coinhive是最大的基于Web的加密货币挖矿服务商，然后我上网查了一下，它目前已经停止运营了。

这个公式中各变量如表5所示。HashSpeed是用户处理器的平均哈希速度，Difficulty是挖一块加密货币的难度，Reward是挖到每个加密货币块获得的奖励。然后前两个变量作者从similarweb.com获取每个检测到的恶意挖矿页面每月的访问者数量及其平均停留时间[32]，表5里的前两项只是举了一个实例。最后计算表明恶意矿工可以每月从超过1000万用户那里获得170多万美元。

其次是这些网站造成的额外的能源消耗。公式中Visitors是每个已识别域的访问者数量，Duration是访问者停留的平均持续时间，这两个变量与上一个公式的前两个变量其实是一样的。 Power是可用于浏览器挖矿的CPU Power，他们是按台式PC中主流CPU的50％，也就是32.5W来算的。最终计算得到恶意挖矿页面每天消耗至少278K千瓦时的电能，相当于美国9.3千万住宅用户的电能消耗。

•恶意矿工的基础设施

这部分首先介绍了挖矿的参与者，然后介绍了这些参与者的分布，试图推断攻击者组织的大小，最后说了一下这些恶意实例的生存周期。

如图5，有四个角色参与恶意挖矿，就是图中虚线里的部分。Attacker是为了获利，利用客户端计算机作为挖矿基础设施的恶意攻击者。他们在客户端上运行的脚本配置有唯一的钱包ID，从而表明谁将收到加密货币的奖励。Miner Deployer是用于加密劫持的主机挖矿脚本，是域或者服务器。这些脚本由攻击者自己制作，或者从其他公共可用资源复制粘贴来的（例如Coinhive）。攻击者可以轻松替换Miner Deployers以规避检测。Mining Pool是分配挖矿任务的域或服务器（任务是指确认正确的哈希结果），并将收入以加密货币的形式返还给矿工。根据作者的分析，他们发现Mining Pool和Miner Deployer通常可以算作同一方，称为Mining Services，比如Coinhive就是这种模式，Mining Services会提供易于使用的加密货币挖矿接口，但是会收取20％到30％的佣金，所以一些攻击者会选择建立自己私人的挖矿服务作为替代，就是不使用现成的这些挖矿服务。Distributor是重定向器，一个中间域，可一个或多个。攻击者通常会经常更改这类域，从而确保它们不出现在任何域或URL的黑名单中。

所以，一旦受害者浏览恶意挖矿页面，恶意挖矿脚本就会被从Attackers指派（钱包ID）的Miner Deployers中获取来。除此之外，一些恶意矿工部署了多个级别的Distributors，这样他们就可以轻松地更改Miner Deployers的URL，从而规避检测。然后挖矿任务是由Mining Pools分配的，在任务完成后会把创造的收入给攻击者。

图6是一个实例，用户访问该汽车交易网，Miner Deployer 中的恶意挖矿脚本通过2个重定向域（右上和左上两个网址）到达受害者的浏览器。然后挖矿脚本使用了ws1.zenoviaexchange.com的Mining Pool。

了解了这些参与者以后，为了进行后续研究，就需要识别这些域，所以接下来作者讲了一下这些参与者在实操中具体是怎么定义的，因为这些参与者最终是各由一组域代表的，所以也就是这些域是如何定义的。

作者首先记录所有访问过的网页的request。Miner Deployers的域可以从加载的检测到的加密劫持脚本的请求URL直接识别，因为它相当于是最终被访问的那个脚本嘛。

如果某个加密劫持脚本被多个request获取，那么我们就考虑是攻击者使用了Distributor，就相当于到达一个加密劫持脚本有多条路径。因此，Distributor的域是除去URL中最终request的其他request。

然后是Mining Pool，作者在监测了一些加密劫持样本之后，发现WebSockets被广泛用于加密劫持脚本和Mining Pool之间的数据转换[12]。也就是说由于Mining Pool使用标准的WebSocket request与Deployer进行通信，因此可以通过属于WebSocket request的域来识别Mining Pool的域。但是WebSocket可能被在线聊天等其他服务使用，从而导致误报，不过从作者的手动分析来看，误报概率还是很小的。

最后Attacker可以通过加密劫持脚本中的钱包ID这一参数值来确定。

接下来作者讲了参与者的分布。但是他们后续只连续监控了1000个样本，然后每3天重新访问一下这些样本。

在实验的第一天作者计算了Miner Deployer，Distributor和Mining Pool的情况，有两个发现。

发现1是大多数恶意矿工不受集中控制。图7显示了Miner Deployers，Distributors或Mining Pools的分布情况。可以看到60％的Mining Pools域，81％的Distributors域和80％的Miner Deployers域出现在不超过三个恶意样本中。所以可以得到恶意矿工是比较分散的，并没有被集中控制的结论，并且因为过于分散，限制了黑名单的有效性。

发现2是挖矿服务和广告商为大多数加密劫持网站提供便利。

表6分别显示了Miner Deployers和Mining Pool的最常见的域。其中，Coinhive与Netflare和Directprimal是加密货币挖矿服务，提供小额支付的替代方案，在线游戏中的人工等待时间，侵入式广告和可疑的营销策略。作者调查发现这些平台的服务条款很模糊，几乎没有人声明矿工需得到用户的同意。并且即使这些挖矿服务会收取高额佣金，还是有超过57.2％的网站会选择这些服务，因为比较方便。

Zenoviaexchange是一家广告服务提供商。除了这一家比较常用，还有许多其他的加密攻击也是由广告服务发起的，大概占加密劫持域的20%，基本都是在不告知用户的情况下挖加密货币。之所以这么多广告服务商参与恶意挖矿，主要还是因为有利可图。

然后作者又研究了一下Miner Deployers和Mining Pools之间的重叠域。他们发现一旦加密劫持网站用常用的挖矿服务作为Miner Deployer，也就是表里的coinhive.com，minescriptsinfo和cryptoloot.pro，他们无一例外地会采用与其相同服务提供商的Mining Pools。表题第二句解释了一下，就是后面带相同标号的是同一服务提供商。它没有标号的相当于是Miner Deployer和Mining Pools是在一起的，也就是我在参与者那部分介绍的Mining Service。

然后这个发现也适用于广告服务。

所以，之所以发现2是挖矿服务和广告商为大多数加密劫持网站提供便利。就是因为他们首先不告知用户，不用经过用户的同意；其次这些常用的Miner Deployers都是提供默认的Mining Pool服务的，比较方便。

然后作者研究了Miner Deployers的URL分配，如图8，231名恶意矿工应用至少一个或多个级别的Distributor。前面那个图6实例就是用了两个Distributor。

图8总结了Distributor链的长度，就是一个URL里的Distributor个数。可以看到超过80个样本使用多个Distributor来获取Miner Deployers的地址，然后最极端的情况是采用四个Distributor域。

之后作者研究了Attacker的情况，得到发现3，大量攻击者获利于滥用加密货币挖矿服务。作者通过分析恶意脚本并自动提取钱包ID，得到图9，可以看到钱包ID通常与少于三个恶意网页相关联。因为刚才表6的时候显示大量攻击者用的是Coinhive，而Coinhive不鼓励从多个钱包中获取利润，并且禁止小额钱包的奖励。因此近一半的恶意样本与钱包ID是一一对应的关系，所以存在大量的攻击者。

最后作者研究了恶意矿工的生命周期，得到发现4，恶意样本经常消失或者更新。如图10显示了加密劫持页面的生命周期，可以看到大约有20％的样本在不到9天内就消失了，表明恶意矿工的生命周期通常都比较短。

作者为了更好地了解更新频率，统计研究了Miner Deployers，Mining Pools或Distributors的域，如表7所示。可以看每列中间那溜儿，就是不仅样本会消失，现有样本也会经常地改变自己的域。就比如9天内就有超过21％（77+88+46）的Miner Deployers迁移到新域。

然后Distributor那列可以看到虽然也有迁移，但是频率比较低。按理说像黑名单这种，监测Distributors这一项会比较省事，结果也会比较全面，但是事实上黑名单并没有这么做。

•检测和规避技术

这部分作者介绍了现有检测技术的有效性以及加密劫持参与者可用的规避技术。

首先，现有检测技术的有效性，作者通过研究得到发现5，比如黑名单这种最先进的缓解加密劫持的措施，并不能及时地定位加密劫持。

作者收集了两个流行的黑名单，如表8所示，左边这个是Github.com中最受欢迎的，有1,469个用户比较喜欢，右边这个是一个广泛使用的黑名单，它有369个用户比较喜欢。从表里可以看出检测率还是蛮低的，并且这两个黑名单的检测域都是集中在Miner Deployers或者Mining Pools，没有一个检测Distributors，表里显示都是0%。而刚刚说了，经过作者上面的实验表明，恶意攻击者很少迁移Distributors。所以作者推测，如果将Distributors添加到黑名单中可能是一种有效的解决方案。

然后作者发现Github日志显示，这些黑名单通常每10到20天更新一次[21,35]，这比上面研究出的加密劫持域的更新速度要慢。图11展示了黑名单更新前后的对比情况。这张图的黑名单是在第9天更新的。结果表明，尽管更新后黑名单的覆盖范围大了一点，但整体检测率仍然不太好，可能是由于这种加密劫持域的高流失导致的，比如前面分析的有许多的域会消失或者迁移等等。

之后作者开始分析加密劫持参与者可用的规避技术，在1,000个跟踪样本中，作者手动分析了100个加密劫持网站，得到表9显示的结果。可以看到常用的规避技术有三种：首先，大多数挖矿页面都避免占用100％的CPU资源。其次，许多恶意页面混淆了恶意负载。最后，一些页面将恶意代码隐藏到比较流行的第三方库中。

第一种限制CPU使用率。为了最大化利润增长，一些加密劫持网页会耗尽用户CPU资源，但是如果这样，用户在访问此类页面时可能会遇到明显的延迟，并且非常容易被一些自动化的方法检测到。所以，大多数加密劫持脚本都不是全速运行的。如图12所示，大多数加密劫持样本的CPU使用率是在3%到90%，而网页的平均CPU使用率为5％[24]，所以仅通过CPU使用率来检测样本是非常困难的。

目前的处理器基本都是多核的，所以加密劫持脚本通常可以利用多线程来处理。但是创建太多的线程也可能降低用户浏览器的性能。因此许多样本不仅为单线程工作负载设置了限制值，还限制了线程的数量。图13显示了加密劫持样本挖矿线程的分布。可以看出只有不到20％的样本使用单线程，大多数的攻击还是并行执行的。然后有大约52％的恶意页面耗尽了挖矿线程，也就是48％的恶意页面限制了挖矿线程的数量。

第二种挖矿脚本的代码混淆。前面给出的100个分析样本中有26个对其代码进行了混淆处理，用来隐藏其恶意的意图。图14是一个真实的例子，这里恶意的有效载荷在第3行进行解码，并在第10行执行。这种规避技术让手动分析师或者静态分析难以理解该恶意有效载荷，从而达到规避的效果。然后作者发现26个样本中只有16个样本是混淆了整个挖矿的有效载荷，其余10个样本则只是简单地混淆了Mining Pools。所以代码混淆经常应用于那些负责分配恶意域的有效载荷。

第三种隐藏有效载荷。这种攻击不是直接将恶意载荷注入到加密劫持网页中，而是选择在第三方库中隐藏其恶意代码。例如，攻击者经常将攻击代码注入他们自己的一个广泛使用的JavaScript库[20]。如图15所示，将恶意代码附加到原始库中，当页面代码加载这个库时，恶意代码就自动触发了。

然后作者通过分析研究上面这些规避技术，将所有样本上传到病毒扫描工具（VirusTotal），并得到发现6，就是这些规避技术对防病毒引擎是有效的。如表10所示，斜杠前是病毒扫描工具检测出的样本数，斜杠后是作者自己设计的检测器检测出的样本数，后面那个百分数就是这两个数据的比率。然后它这个表又分为了使用规避技术和没使用规避技术的情况，以及这两个情况的综合情况。可以看出规避技术还是有效地降低了这些检测工具的检测率的。在综合情况下病毒扫描工具可以检测到大约44%的加密劫持网页，但是当只看使用规避技术的情况时，其检测率下降到了28%。这种规律也适用于表里的前两行数据，也就是Miner Deployers和Distributors。

总体来看，这种防病毒引擎的检测率还是比较低，与黑名单的有效性差不多。然后还可从表10中看出，作者设计的基于行为的检测器可以捕获那些通过规避技术逃脱的脚本，这表明他们设计的检测器比现有的工具更有效。

How You Get Shot in the Back: A Systematical Study about Cryptojacking in the Real World相关推荐

Single Shot Multibox Detection (SSD)实战（下）
Single Shot Multibox Detection (SSD)实战(下) Training 将逐步解释如何训练SSD模型进行目标检测. 2.1. Data Reading and Initi ...
Single Shot Multibox Detection (SSD)实战（上）
Single Shot Multibox Detection (SSD)实战(上) 介绍了边界框.锚框.多尺度对象检测和数据集.现在,我们将利用这些背景知识构建一个目标检测模型:单次多盒检测(SSD) ...
SSD(Single shot multibox detector)目标检测模型架构和设计细节分析
先给出论文链接:SSD: Single Shot MultiBox Detector 本文将对SSD中一些难以理解的细节做仔细分析,包括了default box和ground truth的结合,def ...
PCL中3D特征描述子Shot详解
上周点云公众号开始分享群友们的反馈分享,由博主分配任务,半个月甚至一个月参与学习小伙伴的反馈给群主,并在微信交流群中进行学术交流,加强大家的阅读文献能力,并提高公众号的分享效果.已经有一些开始陆续反馈 ...
棋盘格检测--Automatic camera and range sensor calibration using a single shot
Automatic camera and range sensor calibration using a single shot Robotics and Automation (ICRA), IE ...
分割候选区域--FastMask: Segment Multi-scale Object Candidates in One Shot
FastMask: Segment Multi-scale Object Candidates in One Shot CVPR2017 https://github.com/voidrank/Fas ...
人脸检测--S3FD: Single Shot Scale-invariant Face Detector
S3FD: Single Shot Scale-invariant Face Detector ICCV2017 Caffe code will be available 本文针对基于 anchor ...
目标检测--SSD: Single Shot MultiBox Detector
SSD: Single Shot MultiBox Detector ECCV2016 https://github.com/weiliu89/caffe/tree/ssd 针对目标检测问题,本文取消 ...
（转）Paper list of Meta Learning/ Learning to Learn/ One Shot Learning/ Lifelong Learning
Meta Learning/ Learning to Learn/ One Shot Learning/ Lifelong Learning 2018-08-03 19:16:56 本文转自:http ...

How You Get Shot in the Back: A Systematical Study about Cryptojacking in the Real World

How You Get Shot in the Back: A Systematical Study about Cryptojacking in the Real World相关推荐

最新文章

热门文章