这是自以来2023年六月六日1.2.1更新以来的又一次更新！
全部更新内容参考：
https://github.com/typecho/typecho/compare/v1.2.1...v1.3.0
Typecho v1.3.0 是一个以修复安全和稳定性问题为主的版本，同时包含了一系列的功能改进、性能优化和代码清理。它加强了对现代 PHP 环境的支持（PHP 7.4+），并整合了活跃社区的多项贡献。
理论上，升级此版本将获得更安全、更稳定、体验更好的博客系统。建议所有博友都及时升级。
厂商型号：YR-CP100
主板版本：CP102-MAIN-V2.2
主要芯片：RG200U-CN V3MF-D10-DDC（移远通信）
其他硬件：塑料外壳，3根FPC天线（疑似5G/4G),2根WIFI天线。1个USB Type-C 接口，1个RJ45网线接口。
开盖后取下主板风扇可见各个模块及2个SIM芯片（预计为移动和电信）还有一个空SIM芯片引脚，以及一个没有引出接线位置的SIM卡槽标识位置。
经过不懈努力终于在一众工具中找到了我能正常使用的备份工具。
除了spd_dump是可用的，还有SPRDC_Core也是可用的。但是这两个工具对本设备仍然有一些概率性的玄学问题，比如莫名其妙的信号灯超时时间已到报错。
备份分区表：
<?xml version="1.0" encoding="utf-8"?>
<Partitions>
<Partition id="prodnv" size="4" />
<Partition id="miscdata" size="1" />
<Partition id="recovery" size="16" />
<Partition id="misc" size="1" />
<Partition id="trustos" size="1" />
<Partition id="sml" size="1" />
<Partition id="uboot" size="2" />
<Partition id="boot" size="16" />
<Partition id="system" size="53" />
<Partition id="userdata" size="0xFFFFFFFF" />
<Partition id="nr_fixnv2" size="6" />
<Partition id="nr_runtimenv2" size="9" />
<Partition id="nr_pmsys" size="1" />
<Partition id="nr_agdsp" size="6" />
<Partition id="nr_modem" size="27" />
<Partition id="nr_v3phy" size="6" />
<Partition id="nr_nrphy" size="3" />
<Partition id="nr_nrdsp1" size="2" />
<Partition id="nr_nrdsp2" size="2" />
<Partition id="nr_deltanv" size="1" />
<Partition id="ubipac" size="248" />
</Partitions>这个东西的价格和性能符合我的预期，到的第一天内置移动卡5G测速150Mbps下 50Mbps上，不过这个WI-FI性能就比较怪异了，特别是延迟极端的不稳定，插线用倒是完全没问题，跟手机USB网络共享的热点延迟一致。
通过hexdump查看分区镜像文件数据头部的魔数（Magic Number）为：DHTB
xfox@fedora:~/Dev/YR-CP100$ hexdump /home/xfox/Dev/YR-CP100/all_part_backup/system_payload.bin -C | head -5
00000000 44 48 54 42 01 00 00 00 00 00 00 00 00 00 00 00 |DHTB............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030 00 2e df 01 00 00 00 00 00 2e df 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
查询相关资料可以确定这是紫光展锐设备特有的DHTB分区格式Dynamic Hybrid Trusted Boot，根据已有信息，DHTB分区会把原始分区放置在DHTB数据头后。
直接使用ImHex编辑器查看整个system.img发现0x1000处出现了68 73 71 73 -> hsqs字样。
结合DS对hexdump回显的前几十行原始数据的分析：
根据你之前 hexdump 的结果：
在 0x30 处的值 00 2e df 01 (小端序为 0x01df2e00，约30MB) 很可能指示了**某个数据段的长度。**
在 0x1000 处出现了 68 73 71 73 (hsqs)，这很可能是**一个有效数据块的起始标志**，但它不是UBI格式。
因此，你的 system.img 结构很可能如下：
偏移量 0x0: DHTB 文件头 (包含长度等信息)
偏移量 0x1000: 某个数据块开始 (可能是压缩的映像，如 squashfs)所以确定原始分区是一个基于Linux的SquashFS只读压缩文件系统，通过dd命令取出原始分区:dd if=system.img of=system_payload.bin bs=4096 skip=1
SquashFS分区镜像可以直接挂载。
cat /etc/os-release
ID=unisoc-initgc
NAME="unisoc-initgc-distro"
VERSION="udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
VERSION_ID=udx710-module-unisoc-initgc-1.0-w25.38.5:10.52.14-user-native
PRETTY_NAME="unisoc-initgc-distro udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
DISTRO_CODENAME="sumo"
从Yocto sumo的时间点看貌似是2018年的老版本了，Linux Kernel 4.14.98估计是厂商提供给开发者的SDK。
比较有趣的是，解包后里面开发者写的后台PHP代码基本上和安全俩字没什么关系，连我这个纯外行都能看出来有明显的漏洞，群友们表示尝试过修改镜像并刷回但是因为没有厂商提供的证书签名启动不了。
所以后续Crack完全没必要改来改去硬刷镜像，理论上可以通过Web渗透完成既定目的。
昨天通过对后台PHP代码的查看确定了后台处于不设防的状态:
function quoteArgument($value) {
return empty($value) ? "'null'" : "'{$value}'";
}
function quoteArgument_int($value) {
return empty($value) ? "0" : "'{$value}'";
}
function execShell ($cmd) {
$result = shell_exec($cmd);
$json = json_decode($result);
if ($json->result === 0)
return "success";
else
return "error";
}今天一通尝试，终于构造了post请求拿下了root shell，看/usr/bin有adbd看起来可以启用adbd.
/etc/init.d/下发现了adbd-init 当然，默认是没启用。
扒拉到/etc/usbenum/usbenum.ini
[machine]
machine=udx710-module
[property]
virtualcn=0
diag=1
log=1
debug=1
usbch=mode0
iq_vser=close
udc=29100000.dwc3
afterpowerloss=1
#virtualcn 0-rndis|1-ecm|2-ncm|3-mbim|4-8*AT|5-1*ecm|6-2*ecm|7-3*ecm|8-4*ecm|9-1*ncm|10-2*ncm|11-3*ncm|12-4*ncm|13-test看上去我完全有机会使用USB cdc-ncm 替换RDNIS，当然...前提是能修改好镜像。
似乎可以通过overlay完成对SquashFS的写入存储？但是一改/etc/fstab就涉及现有鸡还是现有蛋的问题了，早于系统启动之前完成修改是不可能的，最终还是得诉诸于修改和重新打包刷入system镜像。
今天和朋友聊到未来发展，经过一番苦劝，思来想去我还是没下定决心去改变攒钱退休的规划。
更轻松的工作和生活方式谁不想有呢？既是我已经失去了对自己自制能力的自信，也是我对自己的学习能力失去了自信。
末了，也是我失去了对未来国家发展的自信。疫情前，至少还一片欣欣向荣，大家想想未来总能有出路。可现在，经济大衰退的环境下，各行各业，包括我自己所接触的行业都已经是行情大砍。我真的不知道自己是否还有努力和自制的能力，也不知道努力究竟能否换来我期许的回报。
眼看又是新的一年，不断的长大或者说老去，只觉人生枯燥乏味，难提拼搏的欲望。
新版QQ采用了类似Electron的技术，所以可以近似看作一个Chromium内核浏览器。
参考资料：
ibus-libpinyin 在 QQ 聊天框中不显示候选词
Using Fcitx 5 on Wayland/zh-cn Chromium / Electron
修改QQ Desktop启动项添加如下参数：--enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime
参考资料：engine.so: cannot enable executable stack as shared object requires: Invalid argument
启动日志：
xfox@fedora:~/.local/share/Steam/steamapps/common/Zombie Panic Source$ ./zps_linux
SDL video target is 'x11'
SDL video target is 'x11'
This system supports the OpenGL extension GL_EXT_framebuffer_object.
This system supports the OpenGL extension GL_EXT_framebuffer_blit.
This system supports the OpenGL extension GL_EXT_framebuffer_multisample.
This system DOES NOT support the OpenGL extension GL_APPLE_fence.
This system supports the OpenGL extension GL_NV_fence.
This system supports the OpenGL extension GL_ARB_sync.
This system supports the OpenGL extension GL_EXT_draw_buffers2.
This system supports the OpenGL extension GL_EXT_bindable_uniform.
This system DOES NOT support the OpenGL extension GL_APPLE_flush_buffer_range.
This system supports the OpenGL extension GL_ARB_map_buffer_range.
This system supports the OpenGL extension GL_ARB_vertex_buffer_object.
This system supports the OpenGL extension GL_ARB_occlusion_query.
This system DOES NOT support the OpenGL extension GL_APPLE_texture_range.
This system DOES NOT support the OpenGL extension GL_APPLE_client_storage.
This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer.
This system supports the OpenGL extension GL_ARB_vertex_array_bgra.
This system supports the OpenGL extension GL_EXT_vertex_array_bgra.
This system supports the OpenGL extension GL_ARB_framebuffer_object.
This system DOES NOT support the OpenGL extension GL_GREMEDY_string_marker.
This system supports the OpenGL extension GL_ARB_debug_output.
This system supports the OpenGL extension GL_EXT_direct_state_access.
This system supports the OpenGL extension GL_NV_bindless_texture.
This system DOES NOT support the OpenGL extension GL_AMD_pinned_memory.
This system supports the OpenGL extension GL_EXT_framebuffer_multisample_blit_scaled.
This system supports the OpenGL extension GL_EXT_texture_sRGB_decode.
This system supports the OpenGL extension GL_NVX_gpu_memory_info.
This system DOES NOT support the OpenGL extension GL_ATI_meminfo.
This system supports the OpenGL extension GL_EXT_texture_compression_s3tc.
This system supports the OpenGL extension GL_EXT_texture_compression_dxt1.
This system DOES NOT support the OpenGL extension GL_ANGLE_texture_compression_dxt3.
This system DOES NOT support the OpenGL extension GL_ANGLE_texture_compression_dxt5.
This system supports the OpenGL extension GL_ARB_buffer_storage.
This system DOES NOT support the OpenGL extension GLX_EXT_swap_control_tear.
OpenGL: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 4.6.0 NVIDIA 580.119.02 (4.6.0)
GL_NV_bindless_texture: DISABLED
GL_AMD_pinned_memory: DISABLED
GL_ARB_buffer_storage: AVAILABLE
GL_EXT_texture_sRGB_decode: AVAILABLE
failed to dlopen /home/xfox/.local/share/Steam/steamapps/common/Zombie Panic Source/bin/engine.so error=/home/xfox/.local/share/Steam/steamapps/common/Zombie Panic Source/bin/engine.so: cannot enable executable stack as shared object requires: Invalid argument
AppFramework : Unable to load module engine.so!
Unable to load interface VCvarQuery001 from engine.soexecstack -c "~/.local/share/Steam/steamapps/common/Zombie Panic Source/bin/engine.so"
如果你使用了其他存储设备存储steam游戏库，应修改为对应的挂载位置。
在这个内存暴涨的时刻，从万能的某宝完成了一次超出某宝默认售后期限的换货。
实际上在这篇文章发布之前找到下载文件损坏和Windows蓝屏崩溃软/硬重启的元凶：光威战将DDR4 3200Mhz 16G*2内存我就已经出现了一些奇奇怪怪的错误，但是直到最近CSGO频繁出现文件错误需要重新校验的问题我才意识到原来这些问题本质上都是内存条的故障导致的。
作为测试的一部分，洗个澡回来接着打CS直到报错为止（之前通常打开一局进入地图时或进入后几秒就报错，为此导致我多次官匹竞技被禁赛掉分）。
打了几把确实没有再出现内存问题导致的报错。
就是比较难受的是原来的是套条，现在这两根一条黑PCB一条绿PCB，neurax看了照片告诉我颗粒一个三星一个镁光，三星那个颗粒还不是一个批次。 就这，还能组成双通道，型号也打的同一个型号，实在是抽象。 除非够便宜不可能再买光威的内存条了，混的有点让人不爽。
疑似和昨天晚上宿舍机房门的打开有关，总之看前缀240e:是中国电信的，有地址和正确的DNS，但是无法访问任何ipv6地址。
限速依旧1.2MB/s 打把CSGO试试有没有提高稳定性。