LiesAuer的 RSS 预览

ColorOS 关闭视频彩铃/运营商视频通话教程

2025-05-22 16:46:00

相信大家打电话时都多多少少遇到过类似下图这样烦人的视频彩铃，下面教大家如何关闭它。

![CleanShot 2025-05-22 at 17.25.03.png](https://storage.liesauer.net/2025/05/2435197187.png)

此教程理论一加/OPPO/真我手机都适用，具体可自行测试。

## 1. 安装 *创建快捷方式* APP
上传的是 zip 压缩包，请先解压再安装 APK。

下载链接：
[创建快捷方式_com.x7890.shortcutcreator_1.17.apk.zip](https://storage.liesauer.net/2025/05/938572345.zip)

## 2. 按图操作
:one:左上角三个点，勾选“搜索活动列表”，再勾选“显示系统应用”
![1.jpg](https://storage.liesauer.net/2025/05/1307028427.jpg)
 
:two:在最上面搜索“移动”，并找到“设置”，点击右边的“活动列表”
![2.jpg](https://storage.liesauer.net/2025/05/2223953555.jpg)
 
:three:点击第一个“移动网络”的“详情”
![3.jpg](https://storage.liesauer.net/2025/05/1550032703.jpg)
 
:four:最下面“附加Action”，选择“自定义”，然后清空右边输入框的内容，最后点击最上面的“打开”按钮
![4.jpg](https://storage.liesauer.net/2025/05/3304015411.jpg)
 
:five:在弹出的设置页面中，找到“运营商视频通话”并关闭，这样子以后打电话就不会再有那些乱七八糟烦人的视频彩铃了。
![5.jpg](https://storage.liesauer.net/2025/05/2085576338.jpg)

## 原教程出处
[3步搞定！OPPO/一加/真我手机视频彩铃关闭教程](https://mbd.baidu.com/newspage/data/videolanding?nid=sv_4729643160189921593 "3步搞定！OPPO/一加/真我手机视频彩铃关闭教程")

豆包文生图超真实随手自拍照

2025-05-17 09:45:00

AI 陪聊通用 PUA 攻击（提示词攻击）

2025-05-14 20:03:00

某 Telegram AI陪聊小程序无鉴权任意用户登录漏洞

2025-03-15 16:39:00

今天整理了一下 AI 方面的资源链接，发现了好几个网页都提到了某 AI陪聊 进行疯狂引流，闲来无事，想着研究一下，发现那叫一个:cow::beer:。

## 登录接口
抓包打开的小程序，发现其登录接口极其简单，最关键的是没发现任何鉴权，只需提供 userid 和 username 即可。
通过搜索关键参数名 `tgUserName`，发现其所需要的参数都是直接挂在 `window` 下的变量。

![微信截图_20250315154259.png](https://storage.liesauer.net/2025/03/3125828712.png)

![微信截图_20250315154507.png](https://storage.liesauer.net/2025/03/2930573445.png)

## 变量追查
通过继续追查 `TelegramUserNameRaw` 变量，发现是直接从 TMA SDK 中获取赋值的，而从最开始进入到加载完都是没有任何其他登录、授权交互的，也就是说用户凭证唯一的来源就是点击小程序入口的链接。

![微信截图_20250315155339.png](https://storage.liesauer.net/2025/03/1987606182.png)

## 入口分析
通过对入口链接做一个简单的 URL Decode，发现确实带了一大坨信息。
![2025-03-15_160624.jpg](https://storage.liesauer.net/2025/03/536359946.jpg)

其中 `tgWebAppData` `auth_date` `signature` `hash` 这几个参数应该是比较重要的，其他参数至少在这个小程序中感觉不是必需的。通过前面对小程序网页、接口的分析，感觉是完全没做鉴权验证的，至少没发现明显的验证相关代码，所以直接搏一搏，把除 `tgWebAppData` 之外的参数全砍了，看下能不能登录。

此时炸裂的来了，确实能够登录，于是乎就想着试下伪造登录。

## 入口伪造
对 `tgWebAppData` 参数进一步研究，发现其实里面也没包含什么信息，就一些常规的用户ID、用户名、昵称、头像等信息包在 JSON 里，都是一些比较好搞的数据。但是现在问题就来了，我从哪里搞到这个网站有哪些用户呢？总不能随机找 TG 用户去碰运气吧？哎，就是这么巧，这个小程序是需要在群组里签到的，也就意味着只要签到群里发送过“签到”的都是注册用户，我就随便挑了一个幸运儿当小白鼠测试。

至于用户ID、用户名这些信息，直接通过 [小鬼当家-ID-BOT](https://t.me/XiaoGuiDangJia_ID_BOT) 这个机器人就能查到。
![微信截图_20250315162637.png](https://storage.liesauer.net/2025/03/1293474463.png)

## 成功伪造登录
拿到用户信息后，修改一下入口链接的参数，重新 encode 一下，丢到浏览器，回车，启动！您猜怎么着，登录进去了，还让我看到了:underage:的内容，雀氏:cow::beer:！

![2025-03-15_155004.jpg](https://storage.liesauer.net/2025/03/4040686480.jpg)

制作标准的 icns 图标

2024-12-24 16:02:00

最近在用 Electron 做一个跨平台的软件，发现打包后 macOS 有图标显示异常的问题，其中包括但不仅限于：
1. 打开 dmg 文件后，图标显示空白
2. 安装后，Launchpad 图标显示空白

初步怀疑是生成的 icns 文件不是标准的，所以无法显示（个别电脑或者系统又能显示）

网上找了很久，也找了很多软件，都不好使，最终找到一篇文章解决了问题，以后会经常用到，特此记录一下。

## 系统要求
1. macOS

需要跑macOS系统自带的程序生成，Windows 和 Linux 都不行，鉴于这是在开发 macOS 软件，这应该不是问题吧？

## 准备图标
准备一个`1024x1024`的 PNG 图标，并命名为`icon.png`。

## 终端生成
打开终端，并`cd`到图标所在的文件夹，运行以下命令。

```shell
mkdir icons.iconset
sips -z 16 16 icon.png --out icons.iconset/icon_16x16.png
sips -z 32 32 icon.png --out icons.iconset/icon_16x16@2x.png
sips -z 32 32 icon.png --out icons.iconset/icon_32x32.png
sips -z 64 64 icon.png --out icons.iconset/icon_32x32@2x.png
sips -z 64 64 icon.png --out icons.iconset/icon_64x64.png
sips -z 128 128 icon.png --out icons.iconset/icon_64x64@2x.png
sips -z 128 128 icon.png --out icons.iconset/icon_128x128.png
sips -z 256 256 icon.png --out icons.iconset/icon_128x128@2x.png
sips -z 256 256 icon.png --out icons.iconset/icon_256x256.png
sips -z 512 512 icon.png --out icons.iconset/icon_256x256@2x.png
sips -z 512 512 icon.png --out icons.iconset/icon_512x512.png
sips -z 1024 1024 icon.png --out icons.iconset/icon_512x512@2x.png
iconutil -c icns icons.iconset -o ./icon.icns
open .
```

运行命令后，你应该就能在打开的文件夹下看到生成的`icon.icns`图标了，最后再次打包测试，发现图标显示都正常了。

## 参考
[macOS App Icon ICNS File Generation Guidelines](https://www.tencentcloud.com/document/product/1219/60589 "macOS App Icon ICNS File Generation Guidelines")

令人崩溃的 Node.js 工具生态

2024-12-08 02:39:00

## 起因
需要对一个开源项目进行二开，然后噩梦从`git clone`之后就开始了。

相关issue：[caorushizi/mediago#362](https://github.com/caorushizi/mediago/issues/362)

## [corepack](https://github.com/nodejs/corepack)
> Corepack是一个零运行时依赖的Node.js脚本，用作Node.js项目与其开发过程中所需的软件包管理器之间的桥梁。从实际角度来看，Corepack允许您在不安装Yarn、npm和pnpm的情况下使用它们。

其他的就不过多介绍了，这个蠢货东西每次运行的时候都不知道发什么鬼请求，在国内环境下，每次运行都会卡住一会，甚至长达几分钟。

解决方法：
1. 挂上梯子
2. 环境变量：`COREPACK_ENABLE_NETWORK`设为`0`

## [node-gyp](https://github.com/nodejs/node-gyp)
这个就不过多吐槽了，懂的都懂，开发个js项目，居然还需要C++环境编译东西，都不知道学的谁家的好本领，关键是很多项目都没写清楚怎么安装所需要的C++环境，实在受不了，装个VS，里面所有C++环境全勾了，好几十G，慢慢装个够吧。:point_left:

## This version of pnpm requires at least Node.js vXXX
真正的噩梦从`pnpm dev`开始，一运行直接给我报了个这错误，当时我百思不得其解，我的Node.js环境明明满足版本要求的，关键是他提示出来的版本号，我压根没装这个版本啊，更奇葩的是他最后打印出来的版本号也是没问题的啊！！！这个牛头不搭马嘴的报错是怎么回事，这个v12版本的Node.js环境又是从哪冒出来的，难不成见鬼了嘛。:neutral_face:
```
> mediago@0.1.0 dev O:\Projects\mediago
> tsx scripts/dev.ts && pnpm --parallel -F "./packages/*" run dev

开始构建 development ...
当前所在的目录是: O:\Projects\mediago
$ npm run types

> mediago@0.1.0 types /mnt/o/Projects/mediago
> pnpm -F main run types

ERROR: This version of pnpm requires at least Node.js v18.12
The current version of Node.js is v12.22.6
Visit https://r.pnpm.io/comp to see the list of past pnpm versions with respective Node.js version support.

/// 省略一大堆报错堆栈信息

Node.js v18.12.0
 ELIFECYCLE  Command failed with exit code 1.
```

然后我去[pnpm](https://github.com/pnpm/pnpm)官方仓库找issue，看下有没有类似的问题，还真找到了好几个，其中都提到了升级pnpm或者使用`@pnpm/exe`这个包解决。

## Cannot find module 'fs/promises'
于是乎我就使用以下命令尝试升级pnpm
```shell
corepack prepare pnpm@latest
```
升级后再次运行`pnpm dev`，嘿，好家伙，报错变了，变成了
```
Cannot find module 'fs/promises'
```

于是乎又上网一通乱搜，说的是这种写法只有在较新版本的Node.js中才支持，关键是我v18是足够新的啊，我其他项目也是有引用过`fs/promises`这个包的，所以非常确定是没问题的。

## This: not found
实在无奈，只能试试`@pnpm/exe`这个包了，这个包是独立版本的pnpm，不依赖任何外部Node.js环境，其自身捆绑打包了一个环境。这个工具也是天才设计，运行所有pnpm命令都会新开一个命令行窗口，而且运行完后会立马关闭，甚至`pnpm -v`都是一闪而过的，想着不想管了，凑合着先用着吧，先把项目跑起来再说，再次`pnpm dev`，一闪而过一长串的东西，不用问了，肯定又有报错了，因为这个命令行窗口是秒关的，为了截取到报错信息，也是费了九牛二虎之力，终于拿到了，嘿，你猜怎么着，报错又变了，这还是我写了这么多年js以来，第一回看到的报错信息，但这回这个报错不想研究了，赶紧把`@pnpm/exe`卸载了，纯当不认识这个包。:sweat_smile:
```
This: not found
```

## 怒删环境
整个晚上整了我这么几回，差点脑溢血，当时就怒删了全部的Node.js环境，pnpm、yarn，各种相关的乱七八糟的全删了，然后去官网整了个v20的重新装了回来，然后用npm把pnpm也装了回来，再次运行，差点气晕过去，又回到了`This version of pnpm requires at least Node.js vXXX`的报错，我的天！！！:tired_face:

## 发现线索
实在没有办法了，开始研究这条命令，发现其实是用`tsx`运行了一个ts脚本，而ts脚本又套娃运行了三条`npm`命令，真的服了，于是乎我就把这三条命令逐条粘贴到终端运行，居然全都是可以跑通的！然后就重点研究这个ts脚本，发现除了运行那三条`npm`命令之外，就引用了[`zx`](https://github.com/google/zx)这个库而已，然后又在[`zx`](https://github.com/google/zx)的issue区逛了一下，大概发现了点东西，其中有些issue提到了wsl，当然也没去细看issue内容，随便逛了一下而已，经过这么一提，我就进wsl里面运行了一下`node -v`，我嘞个豆，出来的版本号就是第一次报错提示的`v12.22.6`，这应该是Ubuntu系统自带的Node.js环境，所以比较旧。

## 问题解决
心好累，不想再研究为啥[`zx`](https://github.com/google/zx)会默认跑到wsl里面运行了，简单去研究了一下[`zx`](https://github.com/google/zx)的玩法，添加以下配置到ts脚本就解决了，好累，睡觉了，再多回想一秒我都会原地爆炸的。:mask:

```ts
if (process.platform === 'win32') {
    $.prefix = '';
    $.shell = 'pwsh.exe';
}
```

其实这里回看第一次出现的报错，其中的日志也是有线索的，前面的输出路径是Windows格式的，后面那三条命令输出的路径已经变成了Linux格式的，当时没发现这个细节。
```
刚开始: O:\Projects\mediago
后面的：/mnt/o/Projects/mediago
```

最后再提一嘴，环境能隔离一定要隔离，别嫌麻烦，装一起用起来固然爽，等出现交叉问题的时候，总能以你这辈子都想象不到的方式出现在你面前。

LiesAuer修改

LiesAuer的 RSS 预览

该作者的社会化媒体

LiesAuer 修改