林夕水共

关于技术，关于生活

发表于 更新于 分类于 Valine：

写在前面的话

自比特币诞生到现在，比特币（网络）经历过大大小小非常多次的攻击，尤其在比特币诞生之初的几年，并且随着比特币价格的一路飙涨，黑客针对比特币网络的攻击就一直没有停止过。据估算，目前大约有 350 ~ 400 万比特币永久丢失，价值大约 240 ~ 280 亿美元。当然其中不只有由于黑客的攻击导致的丢失，毕竟比特币最初的几年很多人都没有意识到比特币的价值，很多的私钥都遗失了。

本文就谈一下目前几种区块链网络攻击，以及其防御方案。

本文尽量用简单易懂的白话来描述，也仅代表我个人的看法，欢迎探讨。

同系列：

异形攻击

异形攻击又称地址污染攻击，是指诱使同类链的节点之间互相发现、互联、侵入的一种攻击手法。同类链的意思是底层 P2P 网络使用了相同或者相似的 P2P 通信协议。这尤其针对比特币和以太坊系列的公链。

众所周知，最近几年区块链行业蓬勃发展，又过于浮躁。其中很多劣质公链大量 COPY 以太坊、比特币的源码，甚至不做修改，仅仅修改下名字成为一条新的公链，这就导致大量的公链的底层是相同的或者兼容的。

那么如果攻击者执行了异形攻击，就有可能导致同类链的节点之间互相缠绕在一起，影响公链节点内部的通信和路由，进而影响到交易、共识和安全。从而让攻击者有机会施行其他的攻击，比如 DDoS 攻击，网络分裂攻击。

本质上还是由于伸手党的存在，并且不加以修饰和对节点的检测造成了异形攻击。应对办法也很简单，首先是拒绝做伸手党，即便伸手党，起码也要研究下别人的代码，做点创新和原创的东西；其次加强对本公链的节点类型的检测，比如节点地址不符合的一切拒绝，通信协议不一致的一切拒绝，通信报文头特殊字段不一致的一切拒绝等等。

配图与本文无关
阅读全文 »

发表于 更新于 分类于 Valine：

写在前面的话

自比特币诞生到现在，比特币（网络）经历过大大小小非常多次的攻击，尤其在比特币诞生之初的几年，并且随着比特币价格的一路飙涨，黑客针对比特币网络的攻击就一直没有停止过。据估算，目前大约有 350 ~ 400 万比特币永久丢失，价值大约 240 ~ 280 亿美元。当然其中不只有由于黑客的攻击导致的丢失，毕竟比特币最初的几年很多人都没有意识到比特币的价值，很多的私钥都遗失了。

本文就谈一下目前几种区块链网络攻击，以及其防御方案。

本文尽量用简单易懂的白话来描述，也仅代表我个人的看法，欢迎探讨。

同系列：

拒绝服务攻击（Denial of Service Attack)

分布式拒绝服务攻击（Distributed Denial of Service Attack)

概念

信息安全的三要素——“保密性”、“完整性”和“可用性”中，拒绝服务攻击，针对的目标正是“可用性”。该攻击方式利用目标系统网络服务功能缺陷或者直接消耗其系统资源，使得该目标系统无法提供正常的服务。

拒绝服务攻击（DoS) 问题一直得不到合理的解决，目前还是世界性难题，究其原因是因为这是由于网络协议本身的安全缺陷造成的，从而拒绝服务攻击也成为了攻击者的终极手法。攻击者进行拒绝服务攻击，实际上让服务器实现两种效果：一是迫使服务器的缓冲区满，不接收新的请求；二是使用IP欺骗，迫使服务器把合法用户的连接复位，影响合法用户的连接。

而分布式拒绝服务攻击 (DDoS) 是指攻击者采用分布式攻击手法施行 DoS 攻击，通常是控制了多台机器向目标主机或者路由器发起 DoS 攻击。

针对区块链来说，攻击者通过 DDoS 攻击试图减慢网络速度，或者迫使网络停止运作。也可用于针对矿池，使矿池脱机，或者针对特定的目标主机，使其从网络离线。

阅读全文 »

发表于 更新于 分类于 Valine：

写在前面的话

自比特币诞生到现在，比特币（网络）经历过大大小小非常多次的攻击，尤其在比特币诞生之初的几年，并且随着比特币价格的一路飙涨，黑客针对比特币网络的攻击就一直没有停止过。据估算，目前大约有 350 ~ 400 万比特币永久丢失，价值大约 240 ~ 280 亿美元。当然其中不只有由于黑客的攻击导致的丢失，毕竟比特币最初的几年很多人都没有意识到比特币的价值，很多的私钥都遗失了。

本文就谈一下目前几种区块链网络攻击，以及其防御方案。

本文尽量用简单易懂的白话来描述，也仅代表我个人的看法，欢迎探讨。

同系列：

女巫攻击（Sybil Attack）

什么是女巫攻击

“女巫”这个词我们应该不陌生，通常指邪恶的化身，并且拥有可怕的魔法。

阅读全文 »

发表于 更新于 分类于 Valine：

写在前面的话

自比特币诞生到现在，比特币（网络）经历过大大小小非常多次的攻击，尤其在比特币诞生之初的几年，并且随着比特币价格的一路飙涨，黑客针对比特币网络的攻击就一直没有停止过。据估算，目前大约有 350 ~ 400 万比特币永久丢失，价值大约 240 ~ 280 亿美元。当然其中不只有由于黑客的攻击导致的丢失，毕竟比特币最初的几年很多人都没有意识到比特币的价值，很多的私钥都遗失了。

本文就谈一下目前几种区块链网络攻击，以及其防御方案。

本文尽量用简单易懂的白话来描述，也仅代表我个人的看法，欢迎探讨。

同系列：

日蚀攻击（Eclipse Attack)

P2P 网络

概念

在介绍什么是日蚀攻击之前，有必要先对区块链系统的底层 P2P 网络做一个简单的介绍，因为日蚀攻击就是利用了 P2P 网络的特性来进行的攻击。

P2P 即 Peer to Peer，中文意思是对等网络，它是分布式系统和计算机网络相结合的产物。对等的意思就是网络中的节点角色、地位是平等的，任何节点具有极强的自由，可以任意加入、离开网络。这跟传统的 C/S 模型的结构有很大区别，任何节点既是 client ，也是 server，或者说网络中没有 server 节点，任何节点 down 掉不会对整个网络产生致命的影响，具有极强的伸缩性。

P2P 网络从诞生到现在经过了几个阶段，分别是混合式 P2P，无结构化 P2P以及结构化 P2P。

  • 混合式：顾名思义，P2P 网络混合了传统的 C/S 模型，网络中有角色充当 server 角色
  • 无结构化：也就是网状结构模型，纯分布式网络，典型代表就是比特币网络，节点之间以一种随机的，松散的方式组织在一起
  • 结构化：节点按照一定规则组织在一起，路由算法比较精准，比如 DHT 算法

混合式
阅读全文 »

发表于 更新于 分类于 Valine：

写在前面的话

自比特币诞生到现在，比特币（网络）经历过大大小小非常多次的攻击，尤其在比特币诞生之初的几年，并且随着比特币价格的一路飙涨，黑客针对比特币网络的攻击就一直没有停止过。据估算，目前大约有 350 ~ 400 万比特币永久丢失，价值大约 240 ~ 280 亿美元。当然其中不只有由于黑客的攻击导致的丢失，毕竟比特币最初的几年很多人都没有意识到比特币的价值，很多的私钥都遗失了。

本文就谈一下目前几种区块链网络攻击，以及其防御方案。

本文尽量用简单易懂的白话来描述，也仅代表我个人的看法，欢迎探讨。

同系列：

51%攻击

在了解什么是 51%攻击前，先简单科普下区块链的几个概念，这里主要以比特币为例作说明。

什么是挖矿？

其实挖矿这个词描述得有点太过于形象了，以至于弄得反而很生涩。当然区块链世界里还有很多玩概念的东西，背后道理其实反而没那么复杂。

在比特币网络里，大家共同在维护一张账目表，参与记账的节点可以称之为矿工，其中矿工需要做的事情就是拼命竞争记账的权利，这个竞争记账权的过程可以称之为挖矿，当一个节点得到这个记账权之后，可以描述为这个节点挖到矿了。那么节点为什么会拼命的竞争这个记账权呢？因为比特币会对挖到矿的节点有奖励。这个奖励是基于区块高度的，最开始是每个区块奖励 50btc，每产生 210000 个区块为一个减半间隔，减半间隔之后奖励会减半。比如目前（2020.04）区块奖励是 12.5btc。

上面这段话里面有两个点需要解释：

  1. 为什么节点要竞争这个记账权？
  2. 区块高度又是什么？

针对第一个问题，如果用比较白话的方式讲的话就是，在分布式去信任的系统中，由于有激励的存在，大家都想拿到这个记账权，但是这个记账权在同一时刻（这里用词不一定表示某一刻，更多的形容相对的同一时刻）只允许其中一个节点拿到，并且由这个节点对交易进行记录。这样才能保证这张账本是唯一的，大家看到的是一样的账本。不然大家都来记账的话，这张账本就乱了，这就是称之为 ”共识“ 的由来。

针对第二个问题，很好理解，区块高度或者说时钟高度，其实是用来描述一个区块的序号的，从创世区块 0 开始依次递增。不用过分纠结，本身是一个很简单的东西，或者叫区块序号更容易理解【手动滑稽】,可以看一下下图：

阅读全文 »

发表于 更新于 分类于 Valine：

前头的话

最近由于手机内存告急，打算对手机进行一下瘦身。其中手机微信占用了将近 5G，这个简直太可怕了，于是打算把微信聊天记录备份到电脑上。本来备份就备份了，也没啥好说的，不过突发奇想想知道 Mac Wechat 把聊天记录备份到哪了？或者说平常聊天的数据放在哪里了？能不能把这些聊天记录导出成 txt 文件呢？

于是就有了这篇文章。

导出微信聊天记录为txt

导出微信聊天记录最简单的一种方式应该是使用 itunes 对 iphone 进行不加密备份，然后找到备份文件里面的数据，据说聊天记录是以明文的方式存在 DB 中的。这种方法我没去试过，这里主要讲一下通过破解微信 DB，读取到聊天记录，然后导出聊天记录。

微信数据目录

1
2
3
4
# 替换其中的 smaug 为你自己的用户名
cd /Users/smaug/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9

find ./ -name "*.db"

以上目录就是微信数据存储的目录，可以看到有很多 db 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
.//37cc38007838aa28296af491b890575f/ChatSync/ChatSync.db
.//37cc38007838aa28296af491b890575f/Message/msg_1.db
.//37cc38007838aa28296af491b890575f/Message/msg_5.db
.//37cc38007838aa28296af491b890575f/Message/msg_4.db
.//37cc38007838aa28296af491b890575f/Message/msg_0.db
.//37cc38007838aa28296af491b890575f/Message/fts/ftsmessage.db
.//37cc38007838aa28296af491b890575f/Message/msg_7.db
.//37cc38007838aa28296af491b890575f/Message/msg_3.db
.//37cc38007838aa28296af491b890575f/Message/msg_2.db
.//37cc38007838aa28296af491b890575f/Message/msg_6.db
.//37cc38007838aa28296af491b890575f/Message/msg_9.db
.//37cc38007838aa28296af491b890575f/Message/msg_8.db
.//37cc38007838aa28296af491b890575f/Sync/openim_oplog.db

其中类似于 msg_0.db、 msg_1.db 的就是聊天记录的数据文件，只不过是加过密的数据库，没法直接看。不过好在有各路大神，可以参考文末的参考链接。

破解步骤

1.打开 Mac Wechat，但是不要登录

2.打开终端，输入命令

1
lldb -p $(pgrep WeChat)

lldb 是在 mac 上的一个调试工具，上面的意思是使用 lldb attach 到 WeChat 这个进程上，进行调试，回车之后进入 lldb 调试界面

3.在 lldb 调试界面输入命令

1
br set -n sqlite3_key

然后回车。

这时调试屏幕上可能会出现一些 error，可以暂时忽略，不用管。

4.输入 c 回车

5.然后正常登录 Mac Wechat，点击登录，手机上点击允许（或者是扫码登录），不用关心此时 Mac Wechat 是否被卡住

6.接着输入命令

1
memory read --size 1 --format x --count 32 $rsi

回车。

读取内存中 寄存器 rsi 存储的值。大致回输出如下的字样：

其中下面的这段是我们关心的：

1
2
3
4
0x604004c346a0: 0xad 0x5c 0xff 0x0a 0x85 0xce 0x4a 0x5e
0x604004c346a8: 0x9f 0x7f 0x8a 0xd3 0xa6 0xc6 0x02 0xf3
0x604004c346b0: 0x25 0x02 0xb1 0x48 0x4c 0x76 0x4c 0x84
0x604004c346b8: 0x82 0x38 0xc3 0x17 0x4d 0x27 0x14 0x33

把前面 0x604004c346b0： 去掉，同时删除后面所有的 0x 和空格，拼接成一个字符串为 (总共 64 个字符）：

1
ad5cff0a85ce4a5e9f7f8ad3a6c602f32502b1484c764c848238c3174d271433

前面加上 0x 就是我们用来破解 DB 的 key:

1
0xad5cff0a85ce4a5e9f7f8ad3a6c602f32502b1484c764c848238c3174d271433

到这里基本上就相当于拿到了微信数据库的 key 了，接下来就是用这个 key 打开 DB 文件了。

TODO(smaug)

发表于 更新于 分类于 Valine：

前头的话

博客已经使用一两年了，最近去看以前的博客的时候发现有些博文里面的图片出现无法显示的情况，虽然问题不是很严重，不过少了图片，就少了很多连贯的东西。之前是采用七牛云存储作为博客图床，可能是因为七牛云存储做了一些限制吧，导致图片无法访问。
这次打算重新换一种图床方式吧，毕竟使用第三方的图床总有跑路的风险。谷歌搜索了一些解决方案，其中一个是使用 Github + jsDelivr + PicGo 的方式作为个人图床的。于是打算试试，本文作为一个试验。

使用 Github 存储图片有一个弊端就是由于 Github 仓库大小有限制，所以到了一定存量的时候，可能需要考虑其他方案或者新建新的仓库。

  • Github： 图片仓库
  • jsDelivr: 一种免费的 CDN 解决方案
  • PicGo: 快速上传图片至 Github 并且自动拷贝图片地址（其实不用这个也行，手动把图片文件 Push 到 Github, 然后拼接图片地址就行）

图床测试

图片1.狼

图片2.SMAUG

图片3.AryaStark

参考

Github+jsDelivr+PicGo 打造稳定快速、高效免费图床

阅读全文 »

发表于 更新于 分类于 ， Valine：

前言

经常做系统分析会接触到很多有用的工具，比如 iostat,它是用来分析磁盘性能、系统 I/O 的利器。

本文将重点介绍 iostat 命令的使用，并分析容易引起误解的几个指标。

iostat

iostat - Report Central Processing Unit (CPU) statistics and input/output statistics for devices and partitions.

上面是 man 手册关于 iostat 命令的介绍，非常简单明了。iostat 是我们经常用来分析 cpu 负载和磁盘 I/O 情况的工具。

iostat 基本使用

常用命令（个人习惯）：

1
iostat -xk 2 10

参数的解释可以查看 man 手册：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
OPTIONS
       -c     Display the CPU utilization report.

       -d     Display the device utilization report.

       -g group_name { device [...] | ALL }
              Display statistics for a group of devices.  The iostat command reports statistics for each individual device in the list then a line of global statistics for the group displayed as group_name and made  up  of  all  the
              devices in the list. The ALL keyword means that all the block devices defined by the system shall be included in the group.

       -h     Make the Device Utilization Report easier to read by a human.

       -j { ID | LABEL | PATH | UUID | ... } [ device [...] | ALL ]
              Display  persistent  device  names.  Options  ID,  LABEL,  etc.  specify  the type of the persistent name. These options are not limited, only prerequisite is that directory with required persistent names is present in
              /dev/disk.  Optionally, multiple devices can be specified in the chosen persistent name type.  Because persistent device names are usually long, option -h is enabled implicitly with this option.

       -k     Display statistics in kilobytes per second.

       -m     Display statistics in megabytes per second.

       -N     Display the registered device mapper names for any device mapper devices.  Useful for viewing LVM2 statistics.

       -p [ { device [,...] | ALL } ]
              The -p option displays statistics for block devices and all their partitions that are used by the system.  If a device name is entered on the command line, then statistics for it and all its partitions  are  displayed.
              Last,  the  ALL  keyword  indicates  that  statistics  have to be displayed for all the block devices and partitions defined by the system, including those that have never been used. If option -j is defined before this
              option, devices entered on the command line can be specified with the chosen persistent name type.

       -T     This option must be used with option -g and indicates that only global statistics for the group are to be displayed, and not statistics for individual devices in the group.

       -t     Print the time for each report displayed. The timestamp format may depend on the value of the S_TIME_FORMAT environment variable (see below).

       -V     Print version number then exit.

       -x     Display extended statistics.

       -y     Omit first report with statistics since system boot, if displaying multiple records at given interval.

       -z     Tell iostat to omit output for any devices for which there was no activity during the sample period.

简单讲，-x 参数能比较详细的给出一些指标，2 代表间隔时间为 2s，统计输出 10 次。

阅读全文 »

发表于 更新于 分类于 ， ， Valine：

最近挺火的微信跳一跳

最近新版微信的『跳一跳』小程序着实火了一把，也把小程序这个概念再次推波助澜了一波，看来以后小程序这个入口会有大作为。

张小龙：一个好的 APP 应该是用完即走的。

这句话对用户来说是个好消息，对其他创业者来说却可能会招来恶语相向。现在这个时代的步伐越来越快，大家好像都很忙，时间越来越珍贵。如果以后微信真的把小程序这个入口做好了，我觉得对于用户来说，是件好事，当然前提是做好了，比如安全性啥的，比如不会被外挂啥的！

现在中午，吃完饭没事大家都会高呼 “来一波！来一波！”，就是微信小游戏『坦克大战』，3V3 玩得不亦乐乎！

废话不多说，看着别人微信跳一跳几百分那么高的分，感觉坐不住了，为了装逼，所以有了这篇博文！

林夕水共是我，这是目前能让好友看到的最高分

阅读全文 »

发表于 更新于 分类于 ， ， Valine：

前言

问题的提出是为了精细化提高 nginx(marxxx) 的性能，遂分析写日志对于请求的影响，上一篇《nginx写日志对于响应速度的影响探究（一）》中其实提出了两个问题还有待研究：

  • log buffer 分别为 4k、64k、128k 不同情况下，相较而言 log buffer 为 64k 时 nginx 性能表现更优，这里的表现指 cpu 压满情况下 qps 更高。so why ?
  • request time 成周期性波动，周期为 60s，即大概每 60s request time 会出现一个突峰，如下图。so why ？
阅读全文 »