无线局域网安全（四）————身份认证之4路握手

╰半夏微凉° 2022-07-16 04:46 783阅读 0赞

前面我们了解了三种加密方式，WEP、TKIP和CCMP，他们分别使用不同的算法给需要传送的MSDU进行加密以后，封装在MPDU中进行传送，然后在接收端对数据进行解密，以达到安全完整传送数据的目的。不管使用哪种加密方式，这都是在STA完成了身份认证以后进行的动作，也就是说在确认了STA获得足够的权限以及拥有正确的密钥以后才能进行安全的、完整的、受保护的的通信。那么对于一个新接入的STA，我们怎么知道它是否拥有足够的权限以及正确的密钥呢？这就涉及到我们将要讲的身份认证以及4路握手过程。

现在我们先了解PTK和GTK：

PTK（pairwise transient key）：成对传输秘钥，它用于单播数据帧的加密和解密

GTK（group temporal key）：组临时秘钥，它用于组播数据帧和广播数据帧的加密和解密，我们前面有提过，管理帧、控制帧和空数据帧是不用加密的

如下图，我们可以看到，在一个加密的BSS中，每个STA都有一个独自的PTK，所有的STA和AP共同拥有一个相同的GTK，

![20161013112015485][]

比如我们比较常见的TKIP和CCMP混合加密，前者用于兼容旧的设备，后者用于规范新的加密，一般来说，为了兼容不同版本的设备，GTK会使用TKIP加密，PTK既可以是TKIP加密，也可以是CCMP加密。

![20161013133507730][]

下面我们来了解一下PTK和GTK的生成，我们前面有了解TKIP和CCMP加密方式，但是对于认证方式没有具体的了解，这里主要介绍preshared key（PSK）和802.1x认证。认证的主要目的是为了确认认证端和被认证端是否拥有相同的PMK和GMK，preshared key（PSK）和802.1x认证主要区别在于MSK的交互，如下图：

![20161013144737645][]

如果使用的是802.1x认证方式，它首先需要进行MSK的交互，然后使用MSK派生出GMK和PMK，这里不讨论802.1x，有机会后面讨论；如果使用的是preshared key，也就是AP和STA都是通过输入密码，然后进行相互鉴定，那么就不需要使用MSK进行派生，通过SSID和pairewise计算出来的PSK就是PMK。

下图是PTK的派生过程：

![20161013150900404][]

如果没有使用PSK，那么PMK是从MSK派生而来的，PMK应该是MSK的前256bit-----MSK: PMK ← L(MSK, 0, 256)

如果有使用PSK，那么PMK就是256bit的PSK

PMK转化成PTK是通过下面的函数完成的：

PTK ← PRF-X(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) ||Min(ANonce,SNonce) || Max(ANonce,SNonce))

（1）其中SNonce是supplicant生成的，ANonce是Authenticator生成的随机数

（2）X = 256 + TK\_bit 是生成的PTK的长度，参数X是256加上对应加密的TK位数，不同的加密方式TK\_bits不一样，可查下表：

![20161013152602990][]

（3）KCK ← L(PTK, 0, 128)，它是PTK的前128bit（0-127），用于计算密钥生成消息的完整性校验值

（4）KEK ← L(PTK, 128, 128)，它是PTK的中间128bit（128–255），用来加密密钥生成消息

（5）TK ← L(PTK, 256, TK\_bits)，它是PTK中256bit以后的所有位（256 — 255 + TK\_bits），用来对数据包中的数据进行加密。从表中可看出，对于TKIP加密PTK的长度是512bit, 对于CCMP加密PTK的长度是384bit。

KCK和KEK将用于后续EAPOL Key帧中某些信息的加密。 TKIP TK和CCMP TK就是TKIP和CCMP算法中用到的密钥。  
明白密钥派生的作用了吗？ 简单来说， WEP中， 网络中传输的是用同一个Key加密后的数据， 其破解的可能性较大。 而TKIP和CCMP则把PMK保存在AP和STA中， 实际数据加密解密时只是使用PMK派生出来的Key， 即PTK。  
因为PTK是由PMK使用

MAC（AA）＋无线网卡MAC（SPA）＋AP产生的随即值（ANonce）＋wifi产生的随机值（SNonce）＋登陆密码（pairewise），

五个值通过SHA256和MD5算法得到的，而这种算法是不可逆的，就算你能知道另外4个值，也是不能求出登陆密码，因而，从PMK中是无法知道登陆密码的，而后面的4路握手过程就是确认对方是否拥有正确PMK的过程。而且每次认证过程都会使用不同的ANonce和SNonce，所以使它更加的安全。

完成各种key的派生以后，STA会使用MLME-SETKEYS.request原语将TK设到网卡驱动里面。

对于AP来说，每一个STA都有各自的PMK，那么怎么来区别和管理他们呢？这就涉及到PMKID，它也和PMKSA（漫游）有关，有机会后面分析。

PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AA || SPA)

前面分析了PTK的派生，接下来分析GTK的派生，这部分比较简单：  
![20161013155912849][]

GMK是一个辅助性的秘钥，它一般用于802.1x认证中，其中GNonce是IEEE 802.1X Authenticator生成的随机数，AA是Authenticator的mac地址，其他的和上面类似，就不在细说了。

上面了解了秘钥的派生过程，接下来分析4路握手的过程：

![20161013162501954][]

**4-Way Handshake Message 1**

首先Authenticator向Supplicant发送一个携带ANonce的EAPOL-Key frame，  
**4-Way Handshake Message 2**

Supplicant将获得的ANonce和AA，这个时候Supplicant已经拥有PMK，AA和SPA，所以可以通过下面的函数计算出PTK

PTK = PRF (PMK + ANonce + SNonce + AA + SPA)  
Supplicant根据ANonce、 自己生成的一个Nonce（ SNonce） 、 自己所设置的PMK和Authenticator的MAC地址等信息进行密钥派生。

Supplicant随后将SNonce以及一些信息通过第二个EAPOL-Key发送给Authenticator。 Message 2还包含一个MIC值，该值会被KCK加密。 接收端Authenticator取出Message 2中的SNonce后， 也将进行和Supplicant中类似的计算来验证Supplicant返回的消息是否正确。 如果不正确，这将表明Supplicant的PMK错误， 于是整个握手工作就此停止。  
**4-Way Handshake Message 3**

如果Supplicant密钥正确， 则Authenticator也进行密钥派生。 此后， Authenticator将发送第三个EAPOL-Key给Supplicant， 该消息携带组临时密码（ Group Transient Key， GTK， 用于后续更新组密钥， 该密钥用KEK加密） 、 MIC（ 用KCK加密） 。 Supplicant收到Message 3后也将做一些计算， 以判断AP的PMK是否正确。 注意， IGTK（ Integrity GTK） 用于加解密组播地址收发的管理帧。  
**4-Way Handshake Message 4**  
Supplicant最后发送一次EAPOL-Key给Authenticator用于确认，如果认证成功， 双方将安装（ Install） Key。 Install的意思是指使用它们来对数据进行加密。

**Controlled Port Unlocked**  
双方完成认证以后，authenticator的控制端口将会被打开，这样802.11的数据帧将能够正常通过，而且所有的单播数据帧将会被PTK保护，所有的组播数据以及广播数据将会被GTK保护。

Supplicant和Authenticator就此完成密钥派生和组对， 双方可以正常进行通信了。

关于4路过程的详细过程可参考《802.11-2012》11.6.6 4-Way Handshake章节，MIC的计算过程可参考前面TKIP和CCMP的文章。

在分析抓包前，先了解一下RSN IE。在一个BSS中，STA和AP之间怎么相互告诉对方自己的RSN特性呢？这就涉及到RSN IE， 它一般在802.11管理帧中进行传送，而且长度是可变的，通过读取其中的信息可以获取每个STA的特性，而且从中可以了解使用的认证方式是802.1x/EAP 认证还是preshared key(PSK)认证。

RSN IE一般在以下4个管理帧中：beacon 帧，probe response, association request, reassociation request。 在BSS中，STA和AP在关联以前，通过这4种帧来相互了解对方所支持的加密特性。比如混合加密中，使用CCMP进行单播加密，TKIP进行组播和广播加密，对应的RSN IE：

![20161013173633797][]

下面结合实际抓包分析一下4路握手：

**Message 1**

![20161013170918364][]

Message 1 uses the following values for each of the EAPOL-Key frame fields:  
Descriptor Type**=** N – see 11.6.2  
Key Information:  
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap  
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other  
cases 0  
Key Type = 1 (Pairwise)  
SMK Message = 0  
Install = 0  
Key Ack = 1  
Key MIC = 0  
Secure = 0  
Error = 0  
Request = 0  
Encrypted Key Data = 0

Reserved = 0 – unused by this protocol version  
Key Length = Cipher-suite-specific; see Table 11-4  
Key Replay Counter =*n* – to allow Authenticator or initiator STA to match the right Message 2 from  
Supplicant or peer STA  
Key Nonce = ANonce  
EAPOL-Key IV = 0  
Key RSC = 0  
Key MIC = 0  
Key Data Length = length of Key Data field in octets  
Key Data = PMKID for the PMK being used during PTK generation or SMKID for SMK being used  
during STK generation  
Processing for PTK generation is as follows:  
The Authenticator sends Message 1 to the Supplicant at the end of a successful IEEE 802.1X authentication,  
after (re)association completes for a STA that has authenticated with SAE or PSK authentication is  
negotiated, when a cached PMKSA is used, or after a STA requests a new key. On reception of Message 1,  
the Supplicant determines whether the Key Replay Counter field value has been used before with the current  
PMKSA. If the Key Replay Counter field value is less than or equal to the current local value, the Supplicant  
discards the message. Otherwise, the Supplicant:  
a) Generates a new nonce SNonce.  
b) Derives PTK.  
c) Constructs Message 2.  
Processing for STK generation is as follows:  
The initiator STA (STA\_I) sends Message 1 to the peer STA (STA\_P) at the end of a successful SMK  
Handshake, when SMKSA is created. On reception of Message 1, the STA\_P determines whether the Key  
Replay Counter field value has been used before with the current SMKSA. If the Key Replay Counter field  
value is less than or equal to the current local value, the STA\_P discards the message. Otherwise, the STA\_P  
a) Generates 256-bit random number that is sent as a peer nonce as part of the Key Nonce field. This  
Nonce is different from the peer nonce generated as part of the SMK Handshake Message 3.  
b) Derives STK.  
c) Constructs Message 2.

**Message 2**

![20161013170925630][]

Message 2 uses the following values for each of the EAPOL-Key frame fields:  
Descriptor Type**=** N – see 11.6.2  
Key Information:  
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap  
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other  
cases 0 – same as Message 1  
Key Type = 1 (Pairwise) – same as Message 1  
SMK Message = 0 – same as Message 1  
Install = 0  
Key Ack = 0  
Key MIC = 1

Secure = 0 – same as Message 1  
Error = 0 – same as Message 1  
Request = 0 – same as Message 1  
Encrypted Key Data = 0  
Reserved = 0 – unused by this protocol version  
Key Length = 0  
Key Replay Counter =*n* – to let the Authenticator or initiator STA know to which Message 1 this  
corresponds  
Key Nonce = SNonce  
EAPOL-Key IV = 0  
Key RSC = 0  
Key MIC = MIC(KCK, EAPOL) – MIC computed over the body of this EAPOL-Key frame with the  
Key MIC field first initialized to 0  
Key Data Length = length of Key Data field in octets  
Key Data = included RSNE – the sending STA’s RSNE for PTK generation or peer RSNE, Lifetime  
of SMK and SMKID for STK generation  
Processing for PTK generation is as follows:  
The Supplicant sends Message 2 to the Authenticator.  
On reception of Message 2, the Authenticator checks that the key replay counter corresponds to the  
outstanding Message 1. If not, it silently discards the message. Otherwise, the Authenticator:  
a) Derives PTK.  
b) Verifies the Message 2 MIC.  
1) If the calculated MIC does not match the MIC that the Supplicant included in the EAPOL-Key  
frame, the Authenticator silently discards Message 2.  
2) If the MIC is valid and it is part of a Fast BSS Transition Initial Mobility Domain Association,  
see 12.4.2. If the MIC is valid and it is not part of a Fast BSS Transition Initial Mobility  
Domain Association, the Authenticator checks that the RSNE bit-wise matches that from the  
(Re)Association Request message.  
i) If these are not exactly the same, the Authenticator uses MLME-DEAUTHENTICATE.request primitive to terminate the association.  
ii) If they do match bit-wise, the Authenticator constructs Message 3.  
c) If management frame protection is being negotiated, the AP initializes the SA Query  
TransactionIdentifier to an implementation-specific non-negative integer value, valid for the current  
pairwise security association.  
Processing for STK generation is as follows:  
The STA\_P sends Message 2 to the STA\_I. On reception of Message 2, the STA\_I checks that the key  
replay counter corresponds to Message 1. If not, it silently discards the message. Otherwise, the STA\_I  
a) Derives the STK.  
b) Verifies the Message 2 MIC using SKCK key. If the calculated MIC does not match the MIC that  
the STA\_P included in the EAPOL-Key frame, the STA\_I silently discards Message 2.  
c) If the MIC is valid, the STA\_I checks that the RSNE bit-wise matches that from the SMK  
Handshake Message 5. If these are not exactly the same, STA\_I silently discards the message and  
restarts the 4-Way Handshake after deleting the existing 4-Way Handshake states.

d) If they do match bit-wise, the STA\_I checks SMKID with the value of SMKID in SMKSA. If these  
are not exactly the same, STA\_I silently discards the message and restarts the 4-Way Handshake  
after deleting the existing 4-Way Handshake states.  
e) If they do match, the STA\_I constructs Message 3. It also compares the Key Lifetime value from the  
KDE with value in its SMKSA. If value in its SMKSA is less, it discards the value received in  
Message 2. Otherwise, it updates the value in SMKSA with value in Message 2.

**Message 3**

![20161013170934083][]

Message 3 uses the following values for each of the EAPOL-Key frame fields:  
Descriptor Type**=** N – see 11.6.2  
Key Information:  
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap  
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other  
cases 0 – same as Message 1  
Key Type = 1 (Pairwise) – same as Message 1  
SMK Message = 0 - same as Message 1  
Install = 0/1 – For PTK generation, 0 only if the AP does not support key mapping keys, or if  
the STA has the No Pairwise bit (in the RSN Capabilities field) equal to 1and only the  
group key is used. For STK generation, this bit is set to 1.  
Key Ack = 1  
Key MIC = 1  
Secure = 1 (keys installed)  
Error = 0 – same as Message 1  
Request = 0 – same as Message 1  
Encrypted Key Data = 1  
Reserved = 0 – unused by this protocol version  
Key Length = Cipher-suite-specific; see Table 11-4  
Key Replay Counter =*n+1*  
Key Nonce = ANonce – same as Message 1  
EAPOL-Key IV = 0 (Version 2) or random (Version 1)  
Key RSC = For PTK generation, starting sequence number that the Authenticator’s STA uses in  
MPDUs protected by GTK. For STK generation, this is set to 0.  
Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) – MIC computed over the body of this  
EAPOL-Key frame with the Key MIC field first initialized to 0  
Key Data Length = length of Key Data field in octets of included RSNEs and GTK  
Key Data = For PTK generation, the AP’s Beacon/Probe Response frame’s RSNE, and, optionally, a  
second RSNE that is the Authenticator’s pairwise cipher suite assignment, and, if a group  
cipher has been negotiated, the encapsulated GTK and the GTK’s key identifier (see 11.6.2),  
and if management frame protection is negotiated, the IGTK KDE. For STK generation  
Initiator RSNE, Lifetime of SMK is used. If the Extended Key ID for Individually Addressed  
Frames subfield of the RSN Capabilities field is 1 for both the Authenticator/STA\_I and  
Supplicant/STA\_P, then the Authenticator/STA\_I includes the Key ID KDE with the assigned  
key identifier.  
Processing for PTK generation is as follows：

If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for  
both the Authenticator and the Supplicant, then the Authenticator assigns a new Key ID for the PTKSA in  
the range 0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLMESETKEYS.request primitive to install the new key in the IEEE 802.11 MAC to receive individually  
addressed MPDUs protected by the PTK with the assigned Key ID. Otherwise the Key ID 0 is used and  
installation of the key is deferred until after Message 4 has been received. The Authenticator sends Message  
3 to the Supplicant.  
NOTE—If an existing PTK is still in effect, the Authenticator IEEE 802.11 MAC continues to transmit protected,  
individually addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the  
Authenticator is able to receive protected, individually addressed MPDUs using either the old key (if present) or the new  
key.  
On reception of Message 3, the Supplicant silently discards the message if the Key Replay Counter field  
value has already been used or if the ANonce value in Message 3 differs from the ANonce value in  
Message 1. The Supplicant also:  
a) Verifies the RSNE. If it is part of a Fast BSS Transition Initial Mobility Domain Association, see  
12.4.2. Otherwise, if it is not identical to that the STA received in the Beacon or Probe Response  
frame, the STA shall disassociate. If a second RSNE is provided in the message, the Supplicant uses  
the pairwise cipher suite specified in the second RSNE or deauthenticates.  
b) Verifies the Message 3 MIC. If the calculated MIC does not match the MIC that the Authenticator  
included in the EAPOL-Key frame, the Supplicant silently discards Message 3.  
c) Updates the last-seen value of the Key Replay Counter field.  
d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is  
1 for both the Authenticator and Supplicant: Uses the MLME-SETKEYS.request primitive to  
configure the IEEE 802.11 MAC to receive individually addressed MPDUs protected by the PTK  
with the assigned Key ID.  
e) Constructs Message 4.  
f) Sends Message 4 to the Authenticator.  
g) Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the  
receive key has not yet been installed, to receive individually addressed MPDUs protected by the  
PTK. The GTK is also configured by MLME-SETKEYS primitive.  
Processing for STK generation is as follows:  
If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is set to 1  
for both the STA\_I and the STA\_P, then the Authenticator assigns a new Key ID for the STKSA in the range  
0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLMESETKEYS.request primitive to install the new key in the IEEE 802.11 MAC to receive individually  
addressed MPDUs protected by the STK with the assigned Key ID. Otherwise the Key ID 0 is used and  
installation of the key is deferred until after Message 4 has been received. The STA\_I sends Message 3 to  
the STA\_P.  
NOTE—If an existing STK is still in effect, the STA\_I IEEE 802.11 MAC continues to transmit protected, individually  
addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the STA\_I is able to  
receive protected, individually addressed MPDUs using both the old key (if present) or the new key.  
On reception of Message 3, the STA\_P silently discards the message if the Key Replay Counter field value  
has already been used or if the INonce value in Message 3 differs form the INonce value in Message 1.  
Otherwise,  
a) The STA\_P verifies the Message 3 MIC using SKCK key in SMKSA. If the calculated MIC does  
not match the MIC that the STA\_P included in the EAPOL-Key frame, the STA\_I silently discards  
Message 3.

b) If the MIC is valid, the STA\_P checks that the RSNE bit-wise matches that from the 4-Way  
Handshake Message 2. If these are not exactly the same, STA\_P silently discards the message and  
deletes existing 4-Way Handshake states.  
c) If they do match, the STA\_P constructs Message 4. It also compares the Key Lifetime value from  
KDE with value in its SMKSA. If value in SMKSA is less, it discards the value received in  
Message 3. Otherwise, it updates the value in SMKSA with value in Message 3.  
d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is  
1 for both the Authenticator and Supplicant then prior to sending Message 4, STA\_P uses the  
MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to receive individually  
addressed MPDUs protected by the STK with the assigned Key ID.  
e) After sending Message 4, STA\_P uses the MLME-SETKEYS.request primitive to configure the  
IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive individually  
addressed MPDUs protected by the STK with the assigned Key ID.

**Message 4**

![20161013170939179][]

Message 4 uses the following values for each of the EAPOL-Key frame fields:  
Descriptor Type**=** N – see 11.6.2  
Key Information:  
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap  
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other  
cases 0 – same as Message 1  
Key Type = 1 (Pairwise) – same as Message 1  
SMK Message = 0 - same as Message 1  
Install = 0  
Key Ack = 0 – this is the last message  
Key MIC = 1  
Secure = 1  
Error = 0  
Request = 0  
Encrypted Key Data = 0  
Reserved = 0 – unused by this protocol version  
Key Length = 0  
Key Replay Counter =*n+1*  
Key Nonce = 0  
EAPOL-Key IV = 0  
Key RSC = 0  
Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) – MIC computed over the body of this  
EAPOL-Key frame with the Key MIC field first initialized to 0  
Key Data Length = length of Key Data field in octets  
Key Data = none required  
Processing for PTK generation is as follows:  
The Supplicant sends Message 4 to the Authenticator. Note that when the 4-Way Handshake is first used,  
Message 4 is sent in the clear.

On reception of Message 4, the Authenticator verifies that the Key Replay Counter field value is one that it  
used on this 4-Way Handshake; if it is not, it silently discards the message. Otherwise:  
a) The Authenticator checks the MIC. If the calculated MIC does not match the MIC that the  
Supplicant included in the EAPOL-Key frame, the Authenticator silently discards Message 4.  
b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure the  
IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive protected,  
individually addressed MPDUs using for the new PTK.  
c) The Authenticator updates the Key Replay Counter field so that it uses a fresh value if a rekey  
becomes necessary.  
Processing for STK generation is as follows:  
The STA\_P sends Message 4 to the STA\_I. On reception of Message 4, the STA\_I verifies that the Key  
Replay Counter field value is one that it used on this 4-Way Handshake; if it is not, it silently discards the  
message. Otherwise,  
a) The STA\_I checks the MIC. If the calculated MIC does not match the MIC that the STA\_P included  
in the EAPOL-Key frame, the STA\_I silently discards Message 4.  
b) If the MIC is valid, the STA\_I uses the MLME-SETKEYS.request primitive to configure the 802.11  
MAC to send and, if the receive key has not yet been installed, to receive protected, individually  
addressed MPDUs using for the new STK.  
c) The STA\_I updates the Key Replay Counter field so that it uses a fresh value if a rekey becomes

[20161013112015485]: /images/20220716/71ba0e66cd71473c8b02f0d551dd87fe.png
[20161013133507730]: /images/20220716/5b769ac0131c4dbd8e33c019b68aa7ec.png
[20161013144737645]: /images/20220716/4345a6a5bce848259a4808e415939823.png
[20161013150900404]: /images/20220716/9b72ce25c491439e8f727e6aa37f9ba3.png
[20161013152602990]: /images/20220716/7ac981336ca744e699be28eab14f8ed3.png
[20161013155912849]: /images/20220716/c416f6d1d6db46a78eda7a85413ce588.png
[20161013162501954]: /images/20220716/e751b7144aa542b9b336c1924e829c61.png
[20161013173633797]: /images/20220716/b0d1758f8c4a493caf64299d52953555.png
[20161013170918364]: /images/20220716/090dc2cfa8dd4dedb514fc068b49de76.png
[20161013170925630]: /images/20220716/eb476223a76a4d038ccf5a83b82ba1bf.png
[20161013170934083]: /images/20220716/3f63806d4eec435c91e110574182d80b.png
[20161013170939179]: /images/20220716/20011cbb5b074bfea35cfd440b43da6b.png