😊 全能顶级web3科学家 😊 初代攻防逆向工具开发者 🍏 全平台逆向分析，你听过没听过的都干过 💔 游戏脱机(web,pc,android,ios) 💜 量化\套利\新闻交易\山寨合约 💚 O-AI (暂停) 蓝V回关
Joined March 2017
- Tweets890
- Following2.9K
- Followers5K
- Likes1K
撸毛的高阶玩法-架构思路及原理详解
一、全自动撸毛总体流程说明
（限于篇幅，只说每个环节原理，细分只能后续独立开篇，部分补充就在回复里吧）。
1.电脑来电自动开机（只需设置bios来电启动）
2.全自动运行脚本任务，机器停电或异常重启（只需将总控程序随系统启动）
3.脚本异常重启（比如使用指纹浏览器，2000个用户id，单机启动多少个浏览器）完成所有任务后，汇报进度到tg，日志写入数据库，方便查看板统计。
这里大致说下思路，如果某些浏览器因为代理原理，项目方网站等原因产生了异常，那么就等待几分钟后再重试，先做下一个浏览器，如果这个浏览器id连续错误达到设定比如5次，就不再重复，而是2000个做完后，tg，wx汇报异常，由人工查看。为什么要这么自动？那既然都说自动化撸毛了，你看完下面的就知道：对，就得唯快不破，要卷只卷自己。
好吧：先上2年前的初始架构图，相对简陋，但太近也不便给你看不是:
二、硬件方便的配置，如何自动化运维。
1.廉价机集群的搭建，如图比如搭建一个便宜的e5集群，建立资源池，一键克隆几百个机器来备用。
用途(仅简单描述，多了一是不好懂，二是几小时也说不完):
1.1 做管理机，可手动处理一些小任务，临时处理某些项目，统一管理，自己电脑不会乱，也更加安全；
1.2 用来执行单任务，一些只需要单开浏览器的，纯图色模拟，ocr识别模拟,这样每次只开一个浏览器，根据任务时间，计算一天的总量，单机一天做几百个浏览器， 例如单虚拟机一天200个浏览器，要做2000，克隆10台即可。
1.3 用来领水,虽然购买2cpacha,CapSolver这样的可以解决临时领水问题，但是每1-2k就是一个猪脚饭了，如果一ip一天又能领取3次，领取半年那消耗就不少，项目多了消耗也大，既然我们都是撸毛了，能节约自然毛都不想给。怎么领？ 但指纹浏览器模拟点击cloudfare这样的主流的就过了，至于其他变态的就不解释了，除了tw这样的，都有解决办法，因为一般领水也不会有。
1.4 搭建局域网文件服务器，数据库服服务器，代理机，即时通讯等(不解释)。
1.5 用来搭建一些节点，一鱼多吃啥的，你买云服务器，那个内存,cpu很是心酸，用你本地的，只需要解决带宽就好,内存比白菜都便宜。配个图吧：
2.高端机器配置，比如最新的i9+3060+显卡+64内存，得有个几台吧。
用途(仅简单描述...):
2.1 用来多开浏览器，这时候需要吃内存，也吃硬盘，带点游戏的项目吃显卡，这样的好处比如单机40开浏览器，可以快速完成2K号的任务，做4K号怎么办？克隆几台就好了，可预装好系统，git同步，连接局域网数据库。 你也可跟网吧一样，ghost多播等。
就不配图了，可能陆续就能看到我其他推文的截图。
2.2 用来临时打手动，都自动化了，还有手动吗？自然,因为就几个小时的任务你写上自动化的时间手都打完了.
三、如何实现脚本的自动化？
1.实现一个主监控，查询数据库，看板，配置参数（比如异常几次，单机开多少个浏览器），全局管理这一台机就看主监控了，配置好主控后，他就会启动启动主脚本控制程序。如图:
2.实现一个脚本控制程序，用于启动浏览器执行脚本， 如果是多开浏览器，是用多线程吗？不，我建议是多进程，这样万一脚本卡主只影响这一个浏览器，就跟chrome一样道理。此程序需要执行脚本执行，就看根据各位语言选择，比如选择js，还是python,lua,或者pascal之类，为什么要用脚本？就是自动git了就执行，不然你得重新编译，项目很多都是短平快，甚至几十种交互，需要修改的，自然就没有效率。如果你不具备构建这些能力，你就会使用一点python，好吧，前面这些就当没说了，思路只是借鉴，你独立执行python就可以了。如图:
3.是否一定要中心数据库？ 是的，你要快，这是必然的，不然局域网这么多机器怎么全自动启动就知道干什么，因为他们都读取数据库配置啊，对应的机器名称，或者他主监控配置，根据读取数据库就知道各自去干什么了，通常我们都没显示器。 当然你就是要跑单机，一个个去处理下又怎么样呢？是的，闲着也是闲着，开心就好。但我们的口号是能机器尽量不人工。
4.还没说到怎么怎么具体跑浏览器自动化? 这个就需要各位根据自己的能力去找对应的解决方案了，搜索下一堆，js在网页是一等公民， python当然因为他的库天下第一，所以建议就这两个，加上需要做脚本载入，自然也他们两个更合适。框架诸如Selenium,Puppeteer,Playwright等。
四、跑协议(脱机)，跑合约？
这个方面，链上基本都是对接rpc，其他需要网页调试，就不展开说，大多时候是一个可选项，或者辅助项，当然你就用这一项完成任务，那么ok，前面的都不用看了，你也似乎没必要看到这里来了。
五、如上自动化怎么对抗女巫的简单说明
1.模拟，加入随机，自然是安全度最高的，鼠标移动，点击按下弹起的时间，输入的速度，这些函数都经过封装后，通常很难被检测的。
脚本的随机时间，因为指纹浏览器每个启动都有一个独立的id，所以每次启动的时候随机启动，其实连自己都不知道规律在哪里，比人工自然随机得多。
2.跑协议，只能凭运气，如果项目方前端检测，因为他的网站是后台更新的，他只要加入一个简单的隐藏参数或者检测，某一天网站更新了，你还在用老版网站数据来交互，但是他也让你协议能正常交互通过，那这时候你该明白么？ 再举个例：就好比他多一个v2接口新网站交互，你一直用v1,请问他网站都更新了，你怎么去打开的v1? 也有一些库，他会检测你的鼠标，键盘的行为，然后提交，所以你协议中并没模拟这个数据，但是你也能交互，最后是否决定你女巫就看项目方了。 再举例：个人认为movment这样的不容易女巫的原因，是因为除了领水你很多交互都是在各自项目方或者galxe这样三方平台上的。
六、安全的问题
1.机器运维安全，首先每台机器防火墙配置，对外不开放端口，保持基本工作在局域网内，
2.代码内不能有敏感数据，比如私钥，钱包密码等，都需要是加密的。
3.如果你有员工，觉得钱包能到处私钥怎么办，我觉得疑人不用是最好的，不然都很难。 有的工作室修改钱包插件来防止员工，但他要真懂卸载重新导入一个插件，或者替换下插件里的钱包文件也是能恢复的，若他真不懂，那心思也就小。 当然你可以用堡垒机，全程录制，用于追溯，但事实上长期跑起来你要防自己人，个人认为多半是不现实的，百密一疏 ，毕竟去中心化零容错，不能像交易所你改个密码就好了。而且丢了不仅是钱，丢了他会很长时间恶心你，比如你还继续撸吗？
4.聊天工具被监控，你做什么在现在大数据时代就不多解释了吧，不中毒都有人能看到，因为隐私问题只是民事， 不起诉都没事，聊天内容审查很多人都有权限看， 甚至普通员工，因为他上面约束的只是法律，懂的都懂。你发出私钥他查看信息，对屏幕拍个照就行。
5.安全总是开始会觉得很注意，一段时间之后一定就松懈了，毕竟要安全就麻烦。
就到这里吧，确实不能用这么一点文字就能表达出太多，就当先抛砖引玉吧。
#web3 #撸毛
AI写书月入百万，我信，但我不服
女作家说AI帮她写书赚了百万美元。
她赚的根本不是"写书"的钱。电子书抽成完到手几块钱，百万美元意味着几十万上百万册的销量，那是畅销榜顶端的量级。她真有这本事，早不用拿AI说事了。所以她赚的更像是"我知道怎么用AI批量搞出一堆能卖的东西，然后卖给那些想靠AI赚钱的人"。跟当年卖"教你做自媒体月入十万"的课，一个内核。
我不否认AI能写。现在模型写个言情大纲、凑个网文开头、水几章甜宠剧情，确实能看。问题是能写和能卖之间差着十万八千里。读者掏钱买书，买的从来不是"字"，是那个写字的人身上附着的某种东西——信任、好奇、陪伴感，或者单纯的"我想看看这人到底什么水平"。AI写的字没有作者，没有那张脸，没有那段"我写这本书的时候刚离婚"的叙事。你让读者为一堆没有来路的文字付费，短期靠营销冲一波可以，长期？书评区第一条就会是"AI味太冲"。
这条新闻的传播路径也挺有意思。一个"女作家"跳出来说"我用AI赚了百万"，媒体一拥而上，标题一个比一个炸。去年是"AI绘画月入五万"，前年是"ChatGPT代写论文月入三万"，大前年是"短视频搬运月入十万"。每隔一阵就有人出来讲一个"新工具+普通人+暴富"的故事，主角永远模糊，数字永远惊人，细节永远经不起追问。她一本书叫什么？哪个平台卖的？分成比例多少？一句没有。全是形容词。
我真正在意的不是她赚没赚到，是这类叙事在喂养一种很坏的东西：把创作简化成"输入指令、输出产品、坐等收钱"的流水线。它暗示年轻人，写东西的门槛不在读了多少、想了多久、疼过几回，而在你会不会写prompt。这跟当年"学会剪辑就能接单""学会排版就能做公众号"是同一种幻觉的升级版。工具越强，幻觉越真，摔下来越疼。
3
8
641
Hook 池的隐形抽水
币安被盗 5.6 亿美元，X 上的讨论全被这件事吸走了，价格跟着往下砸，比特币一度到 7.8 万美元。同一天挂上 arXiv 的一篇实证研究几乎没人转，标题直指 hook 型 DEX 里"未披露的费用"。交易所被外部攻破是巨响，做市池里被合法抽走的钱是细流，后者安静得多，也难查得多。
Uniswap v4 把池子的生命周期切成若干节点——初始化、加流动性、swap、撤流动性、捐赠——每个节点上允许挂一个外部合约去执行自定义逻辑，这就是 hook。费率、限价单、动态手续费、TWAMM 都能做成插件，不用再分叉一套 AMM。产品叙事上很漂亮。问题是，hook 拿到的权限和它需要披露的信息，完全不对等。
一笔 swap 在标准 v3 池里只有一条资金路径：输入 token 进池，按固定费率扣一笔，剩下的按曲线换出。LP 看事件日志里的 Swap 事件，金额、费率、手续费一目了然。到了 hook 池，路径变成用户调用路由合约，路由调用 PoolManager，PoolManager 在 swap 前后各回调一次 hook。hook 在回调里可以干的事包括：swap 前后额外收一笔 ERC20 转账、改动态费率、拒绝这笔交易、甚至自己再发起一次 swap。
重点在"额外收一笔"。假设池子基础费率 0.05%，hook 在 beforeSwap 回调里对输入 token 再收 0.3%，直接转到部署者控制的地址。这笔钱在 PoolManager 的账本里根本不体现为手续费，它只是一次普通的 ERC20 transfer，和用户给朋友转账在日志上长得一模一样。LP 打开区块浏览器，看到 Swap 事件的 fee 字段是 0.05%，池子 TVL 也没变——那 0.3% 从来没进过池子——于是他以为自己赚的是 0.05% 的份额。实际上每一笔交易他都在补贴 hook 部署者。论文里具体的抽成比例和样本池数量素材没给，我不编。但机制本身是硬的：hook 层抽取的费用不进入 LP 可见的费率字段，这是 v4 权限设计的直接后果，不需要实证也能推出来。论文的价值在于它去数了有多少池子真的这么干、干了多少。
除了这层暗抽，还有一笔账要算：hook 调用带来的额外 gas 和失败重试成本。每次 swap 要多执行一次甚至两次外部合约调用，gas 涨了，这笔钱用户付，但用户会把成本折进他愿意接受的报价里，最终压缩的是 LP 能拿到的有效费率。更坑的是 hook 在回调里 revert——交易失败，用户白付 gas，池子什么也没发生。hook 逻辑写得不好，高波动时频繁 revert，LP 面对的是一批根本没能成交的流量，做市库存被动暴露在单边行情里。
LP 在 hook 池里承担的是可编程对手方风险，而他能观测到的只有池子那一层的费率。TVL 高不高和这件事完全无关——TVL 是按当前币价折算的池内资产总额，既不含 hook 抽走的钱，也不反映 LP 的实际净收益。一个池子 TVL 五亿、基础费率 0.01%、hook 暗抽 0.5%，在排行榜上和另一个 TVL 五亿、费率 0.05%、没有 hook 的池子长得一模一样。把 TVL 当 LP 收益的代理指标，在 hook 池上直接失效。
链上自证这条路理论上走得通：把 hook 合约的字节码拉出来，看它在 beforeSwap/afterSwap 里调了哪些 transfer，看收款地址是不是部署者。但这是审计动作，不是日常动作，而且 hook 可以是代理合约，逻辑可以升级，今天干净的字节码明天就换了。事件日志这条路也堵着——EVM 里合约不能读事件，事件只是给链下索引器看的，池子合约自己都不知道 hook 往外转了多少钱。以太坊论坛上那条"合约读不了事件"的帖子说的就是这个老问题，ERC 草案里反复撞上它。
ERC-8472（Stock Locates）和 STVA 那类草案在把更多权限、更多状态塞进合约层，让链上表达更丰富。权限边界扩一寸，可观测性的欠账就多一分。hook 是这个问题最尖锐的样本，因为它把"收钱"和"记账"拆到了两个合约里。监管层面倒是有个可参照的思路：Crypto Council 最近在推 SEC 把金库监管建立在"控制权"上——看谁实际控制资金流，而不是看谁在文件上署名。放到 hook 上，LP 需要知道除了池费率之外还有谁在这笔交易里分钱。比较现实的做法是要求 hook 在初始化时声明一个费用上限和一个收款地址，写进池子的 immutable 参数里，链上索引器就能把它和 Swap 事件对上。v4 的 hook 地址本身就编码了它启用了哪些回调权限，扩展这个编码去带一个费率声明，工程上不算难。
可编程费率确实解决真实需求，动态费率对波动资产是有意义的。但"可编程"被当成纯产品创新讲了一整年，成本结构没人拆。TVL 榜单上那些数字，在 hook 池上，当装饰看就行。
6
9
741
胡说八道, 还很多人不知道，自己都是云里雾里。
DevOps了， 都Dev了，还负责软件安装升级？
1. 约20年前基本行业不会说啥运维，都是系统管理员，网络管理员；
2. 约15年前才有普遍运维工程师这种说法逐渐成了标准术语；
3. DevOps都是近十年才逐渐起来的说法，因docker,k8s这些东西自动化，开发者直接写脚本一键运行，才成了所谓的开发即运维。
核心工作基本都是在开发。
11
2,239
苹果要给笔记本上触控屏了，真机图都流出来了。铰链、屏幕、整体形态看着还挺像回事。乔布斯那句"触控屏笔记本在人体工程学上是糟糕的"又被翻出来，两拨人吵得不可开交。其实这话题苹果自己早就懒得吵了。
苹果做触控 Mac，不是被用户说服了，也不是突然觉得触控是未来，是它没得选。跟当年被迫给 iPhone 换 USB-C 一个性质，被市场按着头做的决定。
乔布斯说触控笔记本糟糕，前提是"你要抬起胳膊戳一块竖着的屏幕"。这判断在 2010 年成立，因为那时候触控的本质就是替代鼠标。但十几年过去，触控在笔记本上的角色早变了——它不再是主要输入方式，而是顺手补一刀。你在 iPad 上刷着刷着，手指自然就点上去了；开会时懒得找触控板，直接戳一下翻页。没人要求你用触控屏写代码，但所有人都默认，一块能摸的屏幕，某些瞬间就是比鼠标快。
苹果真正的问题从来不是触控好不好用，是触控 Mac 会不会杀死 iPad。这才是库克这些年按住不做的原因。iPad Pro 配上妙控键盘，已经长得像一台笔记本了；如果 Mac 也能摸，那 iPad 存在的理由是什么？这个左右互搏的局，苹果拖了快十年，拖到 iPad 销量自己先疲了，拖到 Windows 阵营的二合一都卖成标配了，拖到连 Chromebook 都在学校里把触控当默认配置了。再拖下去，不是苹果教育用户，是用户教育苹果。
Mac 这几年的增长，靠的是 M 系列芯片把性能和续航拉起来，吃的是创意工作者和开发者的换机潮。但这波红利快吃完了。下一波换机靠什么？靠"我的 Mac 能当 iPad 用"这种场景。你看看现在小红书上那些晒桌面的，一半在晒显示器支架，一半在晒怎么把 iPad 当副屏。苹果再不给 Mac 补上这块，用户自己会用外接触控板、用 Sidecar、用各种歪门邪道把需求填上。与其让第三方赚这个钱，不如自己赚。
所以别把这事解读成苹果终于听劝了。苹果从来不听劝，它只在算清楚账之后动手。触控 Mac 真出来，大概率也不是让你举着胳膊戳屏幕，而是配合 macOS 做一套轻触控交互——手指点按、拖拽、双指缩放，仅此而已。它不会变成 Surface，也不会取代 iPad，就是一块顺便能摸的屏幕。
真正值得看的是另一件事：当苹果开始给 Mac 补触控，说明它承认了一件事——设备之间的边界，已经不是它定义的了。用户拿 Mac 当 iPad 用，拿 iPad 当 Mac 用，你拦不住。与其守着乔布斯那句人体工程学，不如把屏幕做成能摸的，然后祈祷用户别发现 iPad 更便宜。
至于那些还在吵触控有没有用的人，这问题在 2024 年已经没有讨论价值了。你去问问身边用 Windows 笔记本的人，有几个是从来不用触控屏的？答案会告诉你，苹果这次不是创新，是补课。补课这件事，从来都不体面，但总比留级强。
2
4
626
链下软肋：PHP漏洞如何穿透Web3的成本账
BlockBeats 把 PHP 那个漏洞定性成"互联网级"高危，加密圈大概没几个人会多看一眼。PHP 太老了，老到没人觉得它跟自己的协议有什么关系。可绝大多数 DeFi 前端跑的就是 PHP 或者跟它同一辈的服务端栈。
被攻破的从来不是共识层。以太坊 TVL 49.0 亿美元、Base 61 亿美元，这些数字躺在链上，任何人拿区块浏览器都能验证，攻击者改不动。能被改的是用户打开网页那一刻看到的东西：前端服务器返回的合约地址、RPC 节点转发的交易内容、签名库里被替换掉的一个函数。用户签的是一笔交易，他信任的却是从浏览器到服务器到 DNS 一整条链路上没人动过手脚。这条链路没有共识保护，没有审计覆盖，出事了也没有哪个保险池会赔。
大部分人把"链下风险"当成一句正确的废话，却说不清钱是在哪一层漏出去的。一个典型场景：项目方把前端托管在某个云服务商，用 PHP 写的后端拼装交易参数，用户点"确认"后由钱包扩展弹出签名框。DNS 被劫持，用户被导向仿冒站点；后端被注入，返回的合约地址被替换成攻击者地址；RPC 节点被控制，交易在广播前被改写；签名库被投毒，用户以为自己签的是授权，实际签的是转账。PHP 漏洞属于第二类，它不需要碰私钥，只需要在服务端把拼装好的 calldata 换掉。用户看到钱包里显示的"与某协议交互"，签名请求本身是合法的，链上执行也完全按代码走——只是对手方地址错了。
链上合约的"不可篡改"在这里帮不上忙。合约确实按代码执行，可代码收到的参数是错的。共识层保证了执行的正确性，保证不了输入的来源。用户在签名框里看到的那个地址，是链下服务器告诉他的，钱包只是把它渲染出来。
项目方有动机防护，但动机强度和资金体量不成比例。一个 TVL 几千万的协议，前端安全预算是运维成本里的一行，能省则省。托管服务商和 CDN 更没动力——他们按流量收费，不为客户的资产安全兜底，合同里写得清清楚楚。最后兜底的是用户，而用户是整条链上议价能力最弱的一环：他既看不到服务端代码，也无法验证 RPC 返回的数据，甚至不知道自己用的前端是不是官方部署的那一份。
审计只覆盖合约。你花几万美金请人看 Solidity，报告出来厚厚一本，里面不会有一页讲前端部署流程。委托范围就这么定的，项目方买的是"合约没漏洞"这个结论，因为那是投资人看得懂的部分。漏洞赏金只奖励已经发现的漏洞，机制的设计前提是有人先发现、再披露、再拿钱。PHP 那个漏洞在被公开之前，有多少项目的前端已经中招、有没有人靠它拿过钱，素材里没有数字，我不猜，但机制上的问题是清楚的：赏金付的是"发现"的钱，不是"预防"的钱，一个从未被发现的链下配置错误永远不会触发任何一笔支出。链上保险只保链上事件，赔付触发条件是合约被攻击、预言机被操纵、清算异常——这些都能在链上留下痕迹，可以被验证、被仲裁。前端被篡改导致的用户资产损失发生在链下，没有链上事件可以锚定，保险协议连理赔的触发条件都写不出来。你没法向一个去中心化保险池证明"我的签名请求被服务端改过"，除非你把浏览器日志和服务器镜像都搬上去，而那已经超出这类协议的验证能力。
X100 Exploit 那条新闻里的资金管理环节，链下敞口是一样的结构——多签的签名人界面、交易构造工具、地址簿同步，任何一处被污染，多签也救不了。
成本错配的准确位置：链上安全有预算、有市场、有定价，因为它的风险可以被观测、被验证、被赔付；链下安全没有这些，因为它的故障模式不产生链上证据。项目方为可观测的风险付费，用户承担不可观测的风险。市场缺了一个能把链下故障转成可定价事件的机制。
补的方向有几个，我都不太看好。把前端也搬到链上，用内容寻址和 ENS 之类的方案让用户验证自己访问的是不是官方版本——技术上成立，可用性上很难，普通用户不会去比对哈希。另一类是让钱包在签名前做更多解析，把 calldata 解码成人话展示给用户，这能减少误签，但防不住地址替换，因为钱包展示的地址本身来自不可信的 RPC。
中间那条路我拿不准：如果 RPC 层出现某种可验证的响应机制，让钱包能证明"这个地址确实是某协议在当前区块的官方部署"，成本会不会被重新分配。这需要协议方、钱包、RPC 服务商三方共同采用一套标准，而目前我没看到哪一方有足够动力先动。a16z 那篇"杀死 Crypto"的论调我不太买账，但它点出的一个事实是对的：当基础设施层的利润薄到没人愿意为安全多付一分钱，标准就推不动。
链下软肋的安全成本，该由谁预付？项目方预付会转嫁成用户的手续费，托管商预付会转嫁成更高的云账单，用户预付——用户根本不知道自己该买什么。现有的审计、赏金、保险三套工具，没有一套是为"还没发生的链下故障"设计的。PHP 这个漏洞会被修掉，下一个不会。
2
6
1,000
