独奏’s BLOG

unraid 公网 Traefik 统一网关

Fri, 18 Oct 2024 00:00:00 GMT

背景

最近玩 pt 使用 qbittorrent 想要增加上传，由于家中是移动宽带无公网 v4，且 qbittorrent 安装在 unraid 上面，因此只能通过公网 ipv6 来增加 bt 上传。

家中的网络是光猫 → 路由 → unraid，光猫与路由桥接，路由负责拨号以及 ipv4 dhcp。

之前 unraid 一直是默认关闭 ipv6，把需要暴露到外网的服务通过 NPS 做端口转发，因此不存在服务暴露在公网的问题，但是开启 ipv6 之后，由于 unraid 获取到公网的 ipv6 地址，意味着上面的所有服务都会暴露到公网，存在一定的安全风险。

综上，需要通过防火墙来屏蔽公网的访问，同时把需要暴露的服务进行放行。这里使用 Traefik 来实现一个统一网关，由网关来对外提供服务。

方案

1. unraid 开启 ipv6

首先需要路由开启 ipv6，让下面的设备能够获取到公网 ipv6 地址，这里不同路由设置方式不同，不详细说明了。

unraid 开启 ipv6 相对简单，首先关闭 docker 和虚拟机服务，在【设置】→【网络设置】→【网络协议】里面选择【ipv4+ipv6】即可。

2. 设置防火墙

开启 ipv6 后，即可发现已经有了 ipv6 公网地址，通过这个地址，再加上你的服务端口（如：http://[2409:8a:xxx:1]:8080），即可在公网直接访问你的服务了。

这样显然是不安全的，我们并不希望所有服务都暴露在公网上。因此需要增加防火墙来防止公网上的访问。

这里需要先安装【user scripts】插件，安装完之后添加一个 script，设置为【At First Array Start Only】即可。第一次设置需要手动执行一次，可以通过ip6tables --list查看规则生效情况。

3. 域名动态解析

配置 Traefik 网关之前，我们需要安装 DDNS-go 服务，能够把域名动态解析到 unraid 的公网 ipv6 上面，这里通过后台配置启用 ipv6 解析即可。

4. Traefik 统一网关

设置好防火墙之后会发现所有服务都无法通过公网 ipv6 地址来访问了。这里我希望能通过域名来访问 alist 等部分服务，因此这里加入了 Traefik 网关来对外提供 http 服务。

首先安装 Traefik，在 unraid 的【应用】中心直接下载 Traefik 即可。Traefik 提供不同的配置方式，网络上大部分都是通过 docker label 来进行配置，但是这样需要修改现有的所有 docker 容器，因此这里我是通过 yml config file 的方式来进行配置。

安装完之后需要创建如下文件：

创建 acme.json

百度WormHole漏洞分析

Wed, 04 Nov 2015 00:00:00 GMT

还记得9月份 Xcode 曝 XcodeGhost 漏洞的时候，网络上一片哗然，大家纷纷叹息一直以安全性著称的 iOS 系统也不再安全了，像微信、网易云音乐等安装量过亿的 APP 纷纷中枪。接着是各种漏洞利用的分析，分析一轮下来，最令人咋舌的就是可以通过这个漏洞来获取用户 appleID 了。

然而事过两个月之后百度 Android APP 被爆出了 WormHole 虫洞漏洞，与其说这是一个漏洞，倒不如说这是百度自己留下的一个后门。百度全系APP连同使用了百度地图的APP纷纷中枪，影响用户同样过亿。该后门之流氓程度与XcodeGhost相比有过之而无不及，包括静默下载任意文件、后台上传用户文件等各种流氓行径。

下面就来分析一下 WormHole 漏洞吧

1. 反编译

首先我从网上公开资料得知在百度地图8.7.0上存在该漏洞，所以我就从『安卓市场』找到了这个版本的百度地图apk，下载下来之后解压得到 classes.dex 文件，接下来需要反编译这个 dex 文件。

使用 dex2jar 反编译这个 dex 文件之后，得到了反编译之后的 jar 文件。

接下来使用 JD-GUI 就可以查看反编译后的 jar 的代码了。

2. 代码分析

查看 jar 代码之后发现百度其实作了代码混淆工作，然并卵。

从公开资料得知 APP 开了一个 http 服务器，监听 40310/6259 端口，而且 APP 中存在geolocation等字符串，通过查找功能，我找到了相关的代码位置。

WormHole

可见文件是在 moplus 的包下的，这个 moplus 其实就是该后门的根源。

通过这个 e.class 我们可以看到，百度做了一个动态调用，通过接口名映射到对应的类里面去，再看这几个类名，惊出一身冷汗，各种权限都有相应的功能接口。

3. 后续

网络上该漏洞利用的相关视频已经不少了，包括静默下载/上传、增加联系人等，都有相关视频。百度在10月28日官方发表声明称已经修复该漏洞，现在是11月4日，我写了个脚本测试内网环境下依然存在该漏洞的机器数目，扫描了255*3个IP，发现了13台机器依然存在该后门。可能会觉得目前存在该后门设备并不算太多，但是公司觉大部分人都是 iPhone 用户，相比于 Android 用户来说，这个数目应该已经算不少了。

目前已经有文章披露百度地图确实在利用此后门在获取用户隐私信息，而且该文章指出这个 moplus 应该是为百度统计服务的。类似获取用户隐私的不光百度一家，包括搜狗、高德地图同样也在通过类似方式获取用户隐私数据。看来对于安卓平台来说，各大厂商暗地获取用户隐私早已成为大家的共识。

另外今天乌云上面又公布了一个 NanoHttpd 的一个相关漏洞，看来是屋漏偏逢连夜雨啊，连工具都出问题了~

参考

有关 XcodeGhost 的问题和解答比葫芦娃还可怕的百度全系APP SDK漏洞 - WormHole虫洞漏洞分析报告 WormHole分析第二弹 Setting the Record Straight on Moplus SDK and the Wormhole Vulnerability NanoHttpd一处设计不当可导致remote-hddr被覆盖

ChatGPT 国内乱象

Fri, 31 Mar 2023 00:00:00 GMT

ChatGPT 确实是一个非常惊艳的产品，不过我也很佩服国内大佬们的赚钱能力，列举下国内利用 ChatGPT 赚钱的几个套路：

卖号：各种机器注册的账号，价格从20元一路打到3元。

建站卖广告：这种最多，搭个web站挂上广告给大家使用，一般都有次数限制。

卖软件：iOS 应用商店各种收费软件。

卖使用次数：微信小程序、web上卖使用次数。

卖企业搭建服务：提供team搭建方案，卖搭建服务。

卖课、卖文章：制造焦虑卖prompt相关课程，卖 ChatGPT 搭建文章。

用来生成文章，短视频

当然，不是说上面的赚钱套路有什么不对，这里只是列举一些隐含的安全问题，大家在使用的时候注意一下。

注册

有条件的同学当然最好还是自己注册，这里说一下卖号的套路。

网上目前能买到的号基本上都是机器注册的账号，单账号价格10元以下吧。

另外官方plus的价格是$20，折合人民币在130+，但是淘宝上一些商家能卖到130元，甚至更低，这种基本上就是信用卡违规操作出来的，同样随时被封。

使用

国内搭建的 ChatGPT 服务基本上都可以认为不安全，因为国内是要求做敏感词屏蔽的，凡是网站带备案，在国内提供服务的，一方面有敏感词屏蔽，另一方面你的聊天记录也是可以从后台看到的。

那么部署在海外的服务就安全么？不见得，现在 ChatGPT 的后端服务做得也很完善了，可以看下这个「小狐狸」系统，专门给 app 和微信小程序做的后台，你的聊天记录从后台同样可以一览无余。

小狐狸后台界面

建议

有条件的最好还是自己搞个梯子来直接使用 ChatGPT 的官方服务。

访问不了的可以退而求其次，使用开源项目来自己搭建，比如：ChatGPT-web、ChatGPT-next-web。

不会搭建的，可以使用开源的 ChatGPT 客户端，比如：ChatGPT-T。

最后还是不推荐大家使用各种免费或付费的二次封装的 ChatGPT 服务。

负数取模

Sat, 27 May 2017 00:00:00 GMT

有两个答案：-7 或 3

这就要说到编程语言对于模运算的定义

这其中对于除法运算 a / b 有两种不同的取整方式，一种是向 0 取整，一种是向负无穷取整。这就导致了取模会有两种结果。

例如：

-7/10 向 0 取整，得到的结果是 0，如果向负无穷取整得到的结果是 -1。因此，如果采用向 0 取整的方式，-7%10 结果就是 -7，如果向负无穷取整，得到的结果就是 3。

到底是向 0 取整还是向负无穷取整，不同的语言实现方式不同，通常默认是按照向 0 取整来计算的，Python 是按照向负无穷取整来计算的，部分语言干脆提供两个函数，rem 和 mod。

有时候确实需要使用向负无穷取整这种方式怎么办呢。可以通过 floor 函数来计算，该函数是向下取整。那么取模变为如下方式:

参考

负数取模怎么算

带符号整数的除法与余数

为什么负数的取余计算各个编程语言结果不统一

取模运算

深入理解RunLoop

Thu, 30 Mar 2017 00:00:00 GMT

事件驱动模型

大部分的 GUI 程序都使用了事件驱动模型，有些服务器(nginx, node.js)也使用了事件驱动模型。相比于轮询等其他方式，其优点在于极大的提高了 CPU 使用率，在没有事件的时候，能够让出 CPU 时间片，来事件时也可以快速的得到响应。

Cocoa 中的 RunLoop

我们常用到的是 NSRunLoop ，其位于 Foundation 框架中。Foundation 框架实际上是 Core Foundation 的部分导出。而 Core Foundation 的源码是开源的。NSRunLoop 实际上是 CFRunLoop 的高层抽象。CFRunLoop 源码可以从这里下载到。

RunLoop 在 Cocoa 中的应用相当广泛。

NSTimer，UIEvent，NSObject (NSDelayedPerforming)，NSObject (NSThreadPerformAdditions)，NSURLConnection 是通过 Source 的机制把事件加入到 RunLoop 中。

Autorelease，CADisplayLink，CATransition，CAAnimation 则是利用 observer 的机制，在 RunLoop 的循环周期中执行各自的操作。

更加底层的 GCD，mach kernel 也与 RunLoop 存在协作关系。

使用 Xcode 调试的时候我们经常可以看到 RunLoop 相关的堆栈信息：

runloop断点

图中可以看到四处关于 RunLoop 的堆栈信息，最上面一条 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ 则是 RunLoop 中的 observer 的 call out 调用。其它的调用还包括：

图中还可以看出 CATransition 利用了 RunLoop 的 observer 做视图的相关操作。

RunLoop 机制

RunLoop结构

这一张图我们可以看出 RunLoop 的组织结构关系。

下面针对各个部分进行了说明

CFRunLoop

CFRunLoop 里面包含了线程，若干个 mode。

CFRunLoop 和线程是一一对应的。

_blocks_head 是 perform block 加入到里面的

CFRunLoopMode

runloop mode 里面包含了source0、source1、timer、observer 各种事件，以及 port 集合。其负责管理这些事件。

CFRunLoopMode 包含下面几种 mode

mode	name	description
Default	NSDefaultRunLoopMode (Cocoa) kCFRunLoopDefaultMode (Core Foundation)	用的最多的模式，大多数情况下应该使用该模式开始 RunLoop并配置 input source
Connection	NSConnectionReplyMode (Cocoa)	Cocoa用这个模式结合 NSConnection 对象监测回应，我们应该很少使用这种模式
Modal	NSModalPanelRunLoopMode (Cocoa)	Cocoa用此模式来标识用于模态面板的事件
Event tracking	NSEventTrackingRunLoopMode (Cocoa)	Cocoa使用此模式在鼠标拖动loop和其它用户界面跟踪 loop期间限制传入事件
Common modes	NSRunLoopCommonModes (Cocoa) kCFRunLoopCommonModes (Core Foundation)	这是一组可配置的常用模式。将输入源与些模式相关联会与组中的每个模式相关联。Cocoa applications 里面此集包括Default、Modal和Event tracking。Core Foundation只包括默认模式，你可以自己把自定义mode用CFRunLoopAddCommonMode函数加入到集合中.

RunLoopSource

RunLoopSource 分为 source0 和 source1。

source0 是非基于 port 的事件，主要是 APP 内部事件，如点击事件，触摸事件等。

source1 是基于Port的，通过内核和其他线程通信，接收，分发系统事件。

__CFRunLoopSource 里面包含一个 _runLoops，也就意味着一个 __CFRunLoopSource 可以被添加到多个 runloop mode 中去。

RunLoopObserver

CFRunLoopObserver 是观察者，可以观察RunLoop的各种状态，并抛出回调。可以监听得状态如下：

RunLoopTimer

CFRunLoopTimer 是定时器，可以在设定的时间点抛出回调

CFRunLoopTimer和NSTimer是toll-free bridged的，可以相互转换。

CFRunLoopGet

RunLoop 和线程是一一对应的

不允许直接创建RunLoop

线程刚创建时并没有 RunLoop, 如果你不主动获取, 那它一直都不会有

你只能在一个线程的内部获取其 RunLoop(main thread 除外)

RunLoop 会在线程销毁时销毁

RunLoop 和线程的一一对应关系保存一个全局 Dictionary 里 __CFRunLoops

即使主线程，不主动创建也不会有 RunLoop，只是 application 会在主线程默认创建 RunLoop

如果创建子线程 RunLoop，主线程会默认加上一个 RunLoop

CFRunLoopRun

RunLoopRun

执行过程大致描述如下：

通知 observers 即将进入 run loop

通知 observes 即将开始处理 timer source

通知 observes 即将开始处理 source0 事件

执行 source0 事件

如果处于主线程有 dispatchPort 消息，跳转到第9步

通知 observes 线程即将进入休眠

内循环阻塞等待接收系统消息，包括：

收到内核发送过来的消息（source1消息）

定时器事件需要执行

run loop 的超时时间到了

手动唤醒 run loop

通知 observes 线程被唤醒

处理通过端口收到的消息：

如果自定义的 timer 被 fire，那么执行该 timer 事件并重新开始循环，完成后跳转到第2步

如果 input source 被 fire，则处理该事件

如果 run loop 被手动唤醒，并且没有超时，完成后跳转到第2步

通知 observes run loop 已经退出

注意：

CFRunLoopDoBlocks 是执行 perform block 中的 block

绿色的是RunLoopRun()

第一次循环 CFRunLoopServiceMachPort 是不走的

handle_msg 处理 timer 事件，处理 main queue block 事件，处理 source1 事件

中间的红色CFRunLoopServiceMachPort是监听 GCD 的端口事件，只监听一个端口，左下角的CFRunLoopServiceMachPort是坚挺 source1,timer 的，是一个 MutableSet

RunLoop 与 GCD

RunLoop 与 GCD 是互相协作的关系，RunLoop 的最开始部分使用了 GCD 的 timer 做超时的回调；通过 GCD 调用带有 RunLoop 的线程的 block，会通过 dispatch port CFRunLoopServiceMachPort 把事件发送到该线程的 RunLoop 里面。

比如：

主线程存在 runloop，那么 GCD 会通过 dispatch port CFRunLoopServiceMachPort，把事件发送给 RunLoop，RunLoop 接收到时间之后，会执行这个 block。

NSTimer 与 GCD Timer

NSTimer 是通过 RunLoop 的 RunLoopTimer 把时间加入到 RunLoopMode 里面。官方文档里面也有说 CFRunLoopTimer 和 NSTimer 是可以互相转换的。由于 NSTimer 的这种机制，因此 NSTimer 的执行必须依赖于 RunLoop，如果没有 RunLoop，NSTimer 是不会执行的。

GCD 则不同，GCD 的线程管理是通过系统来直接管理的。GCD Timer 是通过 dispatch port 给 RunLoop 发送消息，来使 RunLoop 执行相应的 block，如果所在线程没有 RunLoop，那么 GCD 会临时创建一个线程去执行 block，执行完之后再销毁掉，因此 GCD 的 Timer 是不依赖 RunLoop 的。

至于这两个 Timer 的准确性问题，如果不再 RunLoop 的线程里面执行，那么只能使用 GCD Timer，由于 GCD Timer 是基于 MKTimer(mach kernel timer)，已经很底层了，因此是很准确的。

如果在 RunLoop 的线程里面执行，由于 GCD Timer 和 NSTimer 都是通过 port 发送消息的机制来触发 RunLoop 的，因此准确性差别应该不是很大。如果线程 RunLoop 阻塞了，不管是 GCD Timer 还是 NSTimer 都会存在延迟问题。

应用

异步的回调如果存在延时操作，那么就要放到有 RunLoop 的线程里面，否则回调没有着陆点无法执行

NSTimer 必须得在有 RunLoop 的线程里面才能执行，另外，使用 NSTimer 的时候会出现滑动 TableView，Timer 停止的问题，是由于 RunLoopMode 切换的问题，只要把 NSTimer 加到 common mode 就好了。

滚动过程中延迟加载，可以利用滚动时 RunLoopMode 切换到 NSEventTrackingRunLoopMode 模式下这个机制，在 Default mode 下添加加载图片的方法，在滚动时就不会触发。

崩溃后处理 DSSignalHandlerDemo

演示代码

代码中演示了 RunLoop 的不同事件机制，也演示了 GCD Timer 和 NStimer 的区别。

Demo: RunLoopTest

源码注释: source

PPT: 深入理解 RunLoop

参考

深入理解RunLoop RunLoop系列之源码分析 RunLoop系列之要点提炼

计算机浮点数那些事

Sun, 12 Mar 2017 00:00:00 GMT

十进制小数转二进制小数

对十进制小数乘2得到的整数部分和小数部分，整数部分既是相应的二进制数码；再用2乘小数部分(之前乘后得到新的小数部分)，又得到整数和小数部分；如此不断重复，直到小数部分为0或达到精度要求为止。第一次所得到为最高位，最后一次得到为最低位。

如:

0.8125的二进制：

0.81252=1.625 取整是1 0.6252=1.25 取整是1 0.252=0.5 取整是0 0.52=1.0 取整是1

即0.8125的二进制是0.1101（第一次所得到为最高位,最后一次得到为最低位）

0.1 的二进制：

乘数	乘2结果	整数部分	说明
0.1	0.2	0	ㅤ
0.2	0.4	0	ㅤ
0.4	0.8	0	ㅤ
0.8	1.6	1	减1
0.6	1.2	1	减1
0.2	0.4	0	ㅤ
0.4	0.8	0	ㅤ
0.8	1.6	1	减1
0.6	1.2	1	减1
…	…	…	ㅤ

可见，十进制 0.1 转为二进制后为 0.000110011001100110011... 无限循环小数

计算机浮点数表示

计算机存储浮点数遵循 IEEE 754 格式。

V = (-1)^S * M * 2^E

S(Sign/1bit)：符号部分，当 S=0，V 为正数；当 S=1，V 为负数。

E(Exponent/8bits)：指数部分。以2为底。需要注意的是，E 在这里是一个无符号整数，但是实际上指数是可以存在负数的，所以 IEEE 754 规定，E 需要偏移127(64位为1023)，如，2^10 的指数是10，保存成32位浮点数时，必须保存成 10+127=137，即10001001。

M(Mantissa/23bits)：表示有效数字，大于等于1，小于2。第一位 1 可以被舍去，只保留小数部分节省一位有效数字。

指数 E 还分为三种情况：

E 不全为0或不全为1。这时，浮点数就采用上面的规则表示，即指数E的计算值减去127（或1023），得到真实值，再将有效数字M前加上第一位的1。

E全为0。这时，浮点数的指数E等于 1-127（或者 1-1023），有效数字M不再加上第一位的1，而是还原为 0.xxxxxx 的小数。这样做是为了表示±0，以及接近于0的很小的数字。

E全为1。这时，如果有效数字M全为0，表示±无穷大（正负取决于符号位s）；如果有效数字M不全为0，表示这个数不是一个数（NaN）。

IEEE 754 中规定：

对于32位的浮点数，最高的1位是符号位S，接着的8位是指数E，剩下的23位为有效数字M；对于64位的浮点数，最高的1位是符号位S，接着的11位是指数E，剩下的52位为有效数字M。

计算误差

下面以双精度 double 类型的 0.1+0.2 为例

可以发现，由于十进制下的部分小数无法使用二进制精确表示，所以会存在一定的计算误差。在平常应用中我们很少会遇到这个问题，比如遇到支付宝这样的货币系统，需要高精度的计算时，通常我们会定义精确到小数点后两位，然后使用整形来代替浮点型，即使用一分钱的整数倍。