风间苏苏

关于我的图床我的图床网址是 i.imoe.xyz ，在优化前每日下载流量大约为20G左右，优化后下载流量大约5G~6G，为了节省流量成本同时节约存储空间，咱就开始了对图床的优化~ 一些方案首先我希望可以根据用户访问图片时携带的Accept头信息判断用户的浏览器可以展示什么样子的图片，例如 image/webp, image/avif 等，对于新版本浏览器，这个header应该类似于这样 1image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 可以看到avif和webp都是支持的，这个时候只需要在服务端简单判断一下是否包含 image/avif 和 image/webp 就足够了，这个时候只需要服务端对不同accept的访问请求返回不同的图片格式即可 实际使用过程中会发现对于大图片来说webp编码或许可以在几秒钟内完成，但是avif可能会需要数十秒，这就是下面会讲到的内容了 这里需要额外注意一下的是CDN可能没办法很好的根据Accept请求头做缓存，所以这里我的方案是使用302跳转，图片原始链接不会被CDN缓存 ...

0x00 写在开头由于编写这篇文章的时候已经完全处理好了服务器上的挖矿木马，同时也没有记录相关截图，所以大部分内容只能通过文字的方式记录下来，无法提供图片等信息 0x01 发现问题这周周末和往常一样也是睡到了中午才起床，下楼吃饭的时候发现服务器风扇转速比起以往明显变高了很多，我这个时候就登录服务器查看了一下CPU温度等信息，就发现CPU几乎占满但是 htop/top/ps 等工具都无法看到是哪个进程在用CPU 在这里我也尝试了许多不同的方式查看进程信息也都没看到是哪个进程占用CPU非常高，正好我又要出门，保险起见我就直接把服务器关机了 0x02 使用工具在这里我尝试了包括但不限于下列工具： 卡巴斯基企业版（试用，但未成功） ClamAV（按照文档更新数据库直接报错，反复尝试后放弃） rkhunter（成功使用它找到了系统哪些地方被木马动过） 这里就重点提一下rkhunter，用它扫描到了木马用来隐藏自己进程时写入到/etc/ld.so.preload的库，日志如下 12345678[16:42:46] Info: Found library preload file: /etc/l ...

0x00. 前言 本文主要分享一下我个人的动漫资源库管理方案，主要是为了方便自己的管理，也希望能帮助到大家。 不同的人需求不一样，所以本文的方案也不是万能的，只是我个人的一种方案，大家可以根据自己的需求进行调整。 本文的方案需要您在家里有一台NAS或服务器，如果没有就不建议折腾了 0x01. 大致介绍 观看使用Jellyfin+bangumi插件，可以实现观看过的番剧自动同步到bangumi上，省去了手动更新的麻烦。 下载使用的是qBittorrent，配合 Auto_Bangumi 可以做到自动追番，自动下载 为了更好的观看体验，我还使用caddy做了个WebDAV，本地使用PotPlayer+SVP4实时补帧，可以一定程度上提高观看体验。 这里为了方便，除了jellyfin，其他程序均使用docker部署 0x02. qBittorrent12345678910111213docker create \ --name=qbittorrent \ -e WEBUIPORT=8080 \ -e PUID=1026 \ -e PGID=100 \ ...

写在开头 本教程同样适用于服务器监控以及其他BGP网络的监控 本教程只是分享自己的方案，不一定适用于其他场景 咱是 AS4242423396，欢迎来Peer 需要用到的软件 Prometheus: 用于收集其他程序的数据 Grafana: 用于展示Prometheus的数据 Bird_Exporter: 用于收集来自Bird的数据 node_exporter: 用于收集各个节点的基础信息 搭建过程核心部分prometheus 和 grafana 都可以直接使用Docker运行，具体命令如下： 1234# 启动 prometheus$ docker run -d -p 9090:9090 -v /etc/prometheus:/opt/prometheus/config -v /opt/prometheus/data:/prometheus prom/prometheus# 启动 grafana$ docker run -d -p 3000:3000 -v /var/lib/grafana:/opt/grafana grafana/grafana 这里需要注意一点，Prometh ...

注意，在开始之前需要关掉梯子，否则海外版本的bing是没有微软小冰的 首先随便在搜索框打几个字，打开搜索结果页面，这个时候就可以看到右边有个微软小冰，直接点进去就可以看到微软小冰了 首先肯定是先从抓包开始，随便给小冰发几条消息就可以看到如下几个请求 其中 conversationId 很显然是拿来区分不同用户使用的，格式是个uuid 还有一个query，里面的内容就是我们发的消息，但是经过了加密 点开 启动器 ，查看发起请求的相关函数，很容易就可以找到如下的函数 可以看到这里有个明显的AES加密，由于AES加密有好几种，本人才疏学浅没看出来这是哪种，所以就直接把微软的AES代码拿来用了 AES的密钥和其他参数直接在这里下个断点就可以看到了 AES加密用的密钥和位数在我多次使用不同网络环境的不同设备之后确认了这个值不会变，直接写死在代码里面即可 以下内容是我逆向成功的样子

DN42 全称 Decentralized Network 42（42 号去中心网络），它的目标是模拟现实中的BGP互联网，目前它使用了许许多多在互联网上的技术。 在这里你需要像在真实的互联网中一样扮演ISP，申请ASN和IP段，使用BGP广播它们，与其他用户建立连接 需要注意的是你得准备一个Linux设备，如果你像我一样PGP签名用的是yubikey，那么这个Linux设备就必须在本地；如果使用的是软件加解密就可以直接用服务器了 这里需要Linux的原因是Windows文件名不能有冒号，而IPv6的地址中间有冒号，所以必须得用Linux（MacOS大概也可以？） 0x00 准备阶段 然后得去 https://git.dn42.dev/ 注册一个账号，然后 fork 一下 这个 仓库 接下来创建一个名为 你的用户名-日期/register 的分支，例如 theresa-20220522/register 0x01 开始注册mntner在 data/mntner 文件夹中创建 用户名-mnt，内容大致如下 1234567mntner: 用户名（记得大写）-MNT ...

0x00. 写在开头本方案只对正常英文（或其他类似的字母语言）解密生效，对于瞎打一串字母加密之后扔进来不生效，同时对于太短的句子或单个的单词也几乎没用 0x01. 具体方案首先如果是英文，那么你可以在Wikipedia上找到一份英文字母频率表，如下图那么接下来你大概可以猜到要干啥了。 对，我们要把25个密钥全部尝试一遍然后把每个字母出现的频率和这个表对比一遍，找出出现频率和上图中最接近的几个，然后人工确认一遍就行了。 需要注意的是这个方案只能帮你剔除掉大部分错误密钥，不能直接找出正确密钥 下面是我在Google学术上搜cs随便找的一段话加密之后扔给我的机器人自动解密的结果 可以看到这个方案准确率其实还可以 最后补充一个在B站评论区看到的方案： 可以在此基础上多加一个单词表，根据单词表判断解密出的内容是否有意义（来自B站用户：如是默闻）