Snowming04's Blog
区块链安全第一课——自己编写合约：向合约充值
2021-06-02 14:23:07    1507    0    0

博客地址已换，请于此地址查看：

snowming04's new blog

二维码盗 usdt 安全事件分析
2021-06-02 14:16:30    3180    0    0

一、事件概要

昨日，随着微博大v @夏雪宜BTC 的曝光，一种新型骗局进入大家的视线，一时间币圈人人自危：
title

原微博如下：
微博原文

大概是：只要你通过二维码给骗子转过一次 usdt，之后你账户的 usdt 就会被骗子转光。看起来非常正常的二维码交易，为什么骗子在转账一次之后就能控制用户的钱包呢？

下面对犯罪手法做简要分析。

二、过程分析

扫描这个二维码：
title

会访问以下链接：
https://huobi4.gzimtoken.com/trc20.html?s=axu4&addr=TXpSZHhde2UsqQLZMsh14DeKaS1fdRrTuL

点开之后是这样的：
title

使用 TokenPocket 钱包扫码，尝试转账，注意一定是波场链，下图注意左上角：
title

会发现过程中会有如下请求。请注意方法：approve！
title

或者使用 tronlonk 查看：
title

这个合约的形式是 approve，上面这个图的意思是请求批准转账 90000000 usdt！

而此处的请求签名本应该是授权，而 Tronscan 把授权识别成了转账。
现在大家应该明白如果点了接收的后果，approve 授权你就把自己的 usdt 钱包授权给了攻击者的地址，90000000 之内的 usdt 可以被攻击者转走。
这种手法也被称之为 “approve钓鱼” 。

三、继续追踪

请求签名的详情为：
title

从弹出的授权里，看得到是授权给 TVM7gSoNdpgup9SbTKWWY2dHhLVjhehGiy 这个地址，然后去查此地址的转账记录，可以看到 TRC20&TRC721 转入记录全部显示90000000：
title

这些转入账户就全都是受害者。这其实是 tronscan 的 bug，90000000 的只是授权，还不是转账。

比如随便看一笔显示金额为 90000000 的交易：
https://tronscan.org/#/transaction/2c08ccf5c8fcbeab2e994d57a442a5529d295aec7115db131f24256c5db9809a

可以看到授权：
title
也仅仅是授权，这里提示小白，

shellcode windows 编程（三）
2021-04-06 19:11:10    1565    0    1

① 项目代码

根据 https://www.freebuf.com/articles/web/231663.html 一文中展示的 shellcode 生成框架、实现了基于 Win32 API 的远程文件下载功能。

项目代码位于：
https://github.com/Snowming04/shellcode_generate-test_framework

因为此文中原理论述足够清楚，故本文中不再谈论。

② 编译选项

本次工程创建是win32空项目，使用的是VS2019编译relase/x86，编译之前进行如下设置：

  1. 创建工程时关闭SDL检查
  2. 属性->C/C++->代码生成->运行库->多线程 (/MT)如果是debug则设置成MTD
  3. 属性->常规->平台工具集->设置为Visual Studio 2017- Windows XP (v141_xp)，如果没有则可以去安装上对应的兼容xp的组件
  4. 属性->C/C++->代码生成->禁用安全检查GS
  5. 关闭生成清单 属性->链接器->清单文件->生成清单 选择否
  6. C/C++ -> 语言 -> 禁用语言扩展 选择否
  7. C/C++ -> 语言 -> 符合模式 选择否

③ 项目结构

头文件：

  • api.h：在此 头文件中定义实现 shellcode 功能用到的函数对应的签名，以及结构体
  • header.h：shellcode 生成框架中的函数原型

源代码文件：

  • 0.entry.cpp
  • a.start.cpp
  • b.work.cpp：shellcode 功能代码
  • z.end.cpp

其他文件：

  • SCer.exe：快速测试 shellcode 功能的工具

④ 效果展示

title

title

title

⑤ 参考文档

shellcode windows 编程（二）
2021-04-01 11:46:22    1707    0    0

本文希望通过使用 Windbg 调试 kernel32.dll，查看其导出表、 探索 IMAGE_EXPORT_DIRECTORY 数据结构，理解以下三个表之间的相互关系：

  • AddressOfFunctions
  • AddressOfNames
  • AddressOfNameOrdinals

便于更好的理解后续通过函数名称在内存中获取函数指针的 shellcode 编程。

① kernel32.dll 的 Export Directory

将 WinDbg attach 到 C:\Windows\System32\notepad.exe（x64） 程序上。

  1. 0:000> !peb
  2. PEB at 00000093ec76a000
  3.     InheritedAddressSpace:    No
  4.     ReadImageFileExecOptions: No
  5.     BeingDebugged:            Yes
  6.     ImageBaseAddress:         00007ff626d20000
  7.     NtGlobalFlag:             70
  8.     NtGlobalFlag2:            0
  9.     Ldr                       00007fff777053c0
  10.     Ldr.Initialized:          Yes
  11.     Ldr.InInitializationOrderModuleList: 000001986c942ef0 . 000001986c943770
  12.     Ldr.InLoadOrderModuleList:           000001986c9430a0 . 000001986c94a760
  13.     Ldr.InMemoryOrderModuleList:         000001986c9430b0 . 000001986c94a770
  14.                     Base TimeStamp                     Module
  15.             7ff626d20000 5e82e461 Mar 31
shellcode windows 编程（一）
2021-03-29 19:52:12    2056    0    0

本文希望通过 shellcode 编程获取 kernel32.dll 的内存地址。获取 kernel32 的内存地址是通过 LoadLibraryA -> GetProcAddress 调用链进行 shellcode win32 编程的基本步骤。

① kernel32.dll 的内存地址

首先通过 windows c 代码获取 kernel32.dll 的内存地址，用于后续的结果验证。

title

注：编译环境为 win32/x86。

② peb 中寻找 kernel32.dll 的内存地址

已知 peb 中加载的第三个模块是 kernel32.dll。所以 shellcode 作为一段 PIC （位置无关）代码，我们是希望从 peb 中获取 kernel32.dll 的内存地址。

将 WinDbg attach 到 C:\Windows\SysWOW64\notepad.exe（x86） 程序上。

将 PEB 数据结构覆盖在所指向的内存上，以查看该结构成员，在此重点关注 Ldr：

title

Ldr 是一个 _PEB_LDR_DATA 类型的成员，包含有关当前进程加载模块的信息。

title

看到偏移 +0x014 处的成员 InMemoryOrderModuleList。这是一个 _LIST_ENTRY 类型的成员。

title

可以看到这其实是一个双向链表的指针，其有两个成员变量：

  • Flink 指向前一个结点，其大小为一个 x86 指针长度4。
  • Blink 指向下一个结点，其大小为一个 x86 指针长度4。

我们都知道，链表的一个结点，既包含了指针信息，也包含了数据。

title

将此地址覆盖到 LDR_DATA_TABLE_ENTRY 结构查看其数据：

title

可以看到其 Flink（前一个结点）的 FullDllName 为 notepad.exe。但是要注意这是头节点，要获得当前节点的 FullDllName 需要 -8（一个结点长度8字节，因为双向链表结点两个指针 4 bytes *2）：

title

可以看到为当前 exe，即为第1个模块。而我们的目的是查看第3个模块并获取其内存地址。

重新回到 InMemoryOrderModuleLis

一个无厘头问题
2021-02-05 19:02:33    1600    0    0 
  1. MSVCRT.lib(exe_main.obj) : error LNK2001: 无法解析的外部符号 main

遇到这个问题的排错思路是：

  • main 函数是否拼写正确？
  • main 对应 属性→配置属性→C/C++→预处理器→预处理器定义中的 _CONSOLE。以及属性→配置属性→链接器→系统→子系统中的 控制台(/SUBSYSTEM:CONSOLE)，而不要错选成 WINDOWS。

但在这两个前提下，依然报这个错误。那么就要考虑到是否真的编译出 main 函数了。

原来是因为最开始在添加包含 main 函数的源代码文件时候，错选成了 .h 头文件，后面虽然改成了 .cpp 文件，但实质上在解决方案中此文件并未参与编译。于是把此文件从项目中排除然后重新添加现有项就可以了。

注意要点
最后稍微列一下C++包含头文件的顺序，同样来源于上一个引用链接。

要注意的是一些头文件也有依赖关 系，这些文件的包含顺序也小心，否则就会出错。ps,头文件的包含顺序应该是从最特殊到一般，比如：我们应该以这样的方式来#include头文件：
从最特殊到最一般，也就是：

  1. #include "本类头文件"
  2. #include "本目录头文件"
  3. #include "自己写的工具头文件"
  4. #include "第三方头文件"
  5. #include "平台相关头文件"
  6. #include "C++库头文件"
  7. #include "C库头文件"
使用 CNG 实现 AES 加密
2020-11-25 18:39:44    1629    0    1

0x01 什么是 CNG 以及为什么要使用它

本来我在做使用 WIN32 API 加密的时候（比如 AES、RC4） 是通过 CSP 实现的。CSP 是一个独立的软件模块，实际上执行用于身份验证，编码和加密的密码算法。CSP 提供了一组密码学 API，使应用程序开发人员可以向基于 Windows 的应用程序添加身份验证，编码和加密。

但是现在有了新一代密码学 API，也被称为 CNG（Cryprography API: Next Generation），MSDN 号称：

之前的 Cryptography API 不再推荐使用。

如：

  • CryptAcquireContextA
  • CryptCreateHash
  • CryptDeriveKey
  • ...

新的和现有的软件应开始使用Cryptography Next Generation API。Microsoft可能会在将来的版本中删除之前的 Cryptography API。

本文就是使用 CNG（新一代密码学 API）来示范 AES 的使用，因为避免关联，不会给出完整代码，使用的尽量是 MSDN 上的代码或来源于其他合法渠道的公开代码示例。

0x02 实现 AES CBC 模式

CBC 模式是需要使用 IV 的。IV 即初始化向量，相比于 ECB 模式，CBC 模式对每个明文分组要与前一个密文分组进行异或，这样的作用是即时两个明文分组的值是相等的，经过多字节异或，对应的两个密文分组的值也不一定是相等的。而IV 的使用就是为了解决第一个明文分组跟谁异或的问题。

当加密第一个明文分组时，由于不存在“前一个密文分组”，因此需要事先准备一个长度为一个分组的比特序列来代替“前一个密文分组”，这个比特序列称为初始化向量（Initialization Vector），通常缩写为IV，一般来说，每次加密时都会随机产生一个不同的比特序列来作为初始化向量。

这里要注意，IV 的长度与分组的大小是一致的。而 AES 的标准分组为 128 Bits，即为 16 字节。

AES 有三个输入和一个输出：

  • 输入1：IV。IV 不得大于16字节，如果用户输入大于则截断，小于则填充0。
  • 输入
Cobalt Strike 宏样本生成的错误
2020-11-20 17:53:41    966    0    0

CS （测试版本 4.0）生成的默认宏样本，如下定义此结构体：

  1. Private Type PROCESS_INFORMATION
  2.     hProcess As Long
  3.     hThread As Long
  4.     dwProcessId As Long
  5.     dwThreadId As Long
  6. End Type

但其实：

  1. hProcess As Long
  2. hThread As Long

在64位机器环境下均定义错误。

因为 64 位环境下， VBA 中 Long 仅为4字节，如果按照这个宏样本去运行，取第三个参数的值，就会发现并不是正确的 PID：

  1. Debug.Print pInfo.dwProcessId

但 CS 的默认宏样本却能正确运行，这是因为 hProcess 不过是一个进程句柄，是可以被4字节容纳下的。但是错误的内存大小定义会影响到占位和第三个参数的值，所以应该根据系统选择性的定义：

  1. #If VBA7 And Win64 Then
  2. Private Type PROCESS_INFORMATION
  3.     hProcess As LongPtr
  4.     hThread As LongPtr
  5.     dwProcessId As Long
  6.     dwThreadId As Long
  7. End Type
  9. #Else
  10. Private Type PROCESS_INFORMATION
  11.     hProcess As Long
  12.     hThread As Long
  13.     dwProcessId As Long
  14.     dwThreadId As Long
  15. End Type
  17. #End If

注： LongPtr 在64位系统中为8字节。

探索 PEB
2020-11-10 21:39:48    948    0    0

因为蚂蚁笔记官方图片服务器极其不稳定，请直接转到此链接查看：

《探索 PEB》
https://shimo.im/docs/jRwpvxXYPwPw9Cdd/

我太懒了，有机会的话会换博客服务器。

利用纤程进行 Shellcode 本地进程注入
2020-11-09 15:26:44    1746    0    0

什么是纤程（Fibers）？

用一个类比：线程是进程内部的实体，那么纤程则又是纤程内部的实体。

在《Windows Internals（第六版）》一书中提到：

因为将 CPU 的执行从一个线程切换到另一个线程，将不可避免地涉及内核调度器，所以，这可能是一个开销昂贵的操作，如果两个线程经常频繁地来回切换则尤其如此。 Windows 实现了两种机制来降低这一开销：纤程（fiber）和用户模式调度（ UMS , user-mode scheduling ）。

纤程使得一个应用程序可以调度它自己的“线程”的执行过程，而不必依赖于 Windows 内置的基于优先级的调度机制。纤程也常被称为“轻量”线程：从调度的角度来看，它们对于内核是不可见的，因为它们是在用户模式下在 Kemel32.dll 中实现的。为了使用纤程，首先要调用 Windows 的 ConvertThreadToFiber 函数。该函数将当前线程转变成一个正在运行的纤程。之后，在转变得到的纤程中，通过调用 CreateFiber 函数，又可以创建额外的纤程（每个纤程可以有它自己的一组纤程）。然而，与线程不同的是，纤程不会自动执行，它必须由 SwitchToFiber 函数手工选中，然后才能执行。新的纤程会一直运行，直到退出，或者调用SwitchToFiber再次选择运行另一个纤程。

总结一下，纤程是执行单元，其必须由应用程序进行手动调度。纤程在对其进行调度的线程的上下文中运行。

本文中，企图通过利用和纤程相关的 Win32 API，来在本地进程中执行 shellcode。绕过一些防御设备对常见进程注入 API 的拦截。

为了使用纤程执行 Shellcode，调用链为：

  1. 将主线程转换为纤程1（这是必需的，因为只有一个纤程才可以创建另一个纤程）。使用 ConvertThreadToFiber 函数。
  2. 将shellcode写入某个内存位置并使其可执行，获取指向此位置的指针。可使用 VirtualAlloc + memcpy 函数。
  3. 创建一个指向 Shellcode 位置的新纤程2——我们将使用在第一步中通过主线程转的纤程1来创建此纤程2。使用 CreateFiber 函