i1nfo

本文测试平台： iPhone5s: iOS 12.5.5(Jailbroken by unc0ver 8.0.2) MacBook Pro (2021): macOS 12.5 本文将主要基于对易校园 App 进行的相关测试分析，文中简写为 yxy 砸壳/脱壳本文中的砸壳指的是去除 App Store 对应用添加的加密。本文不细探究砸壳原理。 砸壳原理以及手动砸壳推荐参考文章： iOS逆向(11)-砸壳原理剖析，主动加载所有framework 工具 flexdecrypt 静态 Mach-O 二进制解密工具 appdecrypt 静态 Mach-O 二进制解密工具，工作原理同 flexdecrypt CrackerXI+ iOS 端自动砸壳工具， 可以通过添加（如 http://cydia.iphonecake.com 源）安装。动态脱壳，生成 ipa。 其他老牌的砸壳工具如 Clutch, dumpdecrypted, frida-ios-dump 也能够动态砸壳生成ipa。 对于不同的app应该根据情况来使用工具，并不能保证存在某个万能的砸壳工具。 解密 ...

关键词：NVIDIA, Arch Linux, suspend 最近好不容易迁移到了Wayland，但是小问题还是不少，其中一个关键问题就是从休眠(suspend)恢复后（此问题貌似与Wayland无关），gnome-shell中的文字和图标大多消失了，GUI只剩下骨架。 在网上搜索GNOME休眠后文字消失(google: gnome missing characters after suspend)相关问题，大多都是若干年前的讨论，经过测试，对于我的情况没有任何帮助（大多是和当初的Intel核显驱动或N卡开源驱动还有Linux内核有关）。当然最后还是找到了一定帮助的文章，才把问题定位到了NVIDIA闭源驱动上。 在Fedora论坛找到了最近几个月关于此问题的讨论，才知道NVIDIA Suspend已经成为了一个标准问题。Arch Linux Wiki也有相关的解决方案，其中也指出了NVIDIA驱动的说明文档的链接（还好有NVIDIA官方解决方案）。推荐阅读一下官方提供的说明文档。 Arch Wiki描述的过于简单，中间还是有一些坑的，既然坑我已经踩了，下面直接放上最终解决方案好了 ...

前情提要：听说Linux上N卡闭源驱动有了较大的更新，比如添加了drm和Xwayland硬件加速支持。正好手头Manjaro滚炸了(很久没更新了，大概跟新驱动有关)，直接新装Arch Linux + GNOME + Wayland套餐。不过中间Wayland之路经历了很多曲折，期间多次放弃Wayland滚回Xorg。。。 仅仅提供一个参考，具体还得看平台和使用场景。 环境： Host: MSI GS66 Stealth 10SF OS: Arch Linux with Stable kernel CPU: Intel i7-10750H GPU: NVIDIA GeForce RTX 2070 Mobile 如上图，标准的I+N双显卡游戏本。 注意，在写本文的时候，I+N方案Wayland支持程度仍然很差，当然使用Xorg性能也依然不佳(不然也不会想方设法去用Wayland 本文默认已经装好Arch Linux和GNOME，并且使用的是稳定版(非lts)内核。 NVIDIA闭源驱动安装参考Archwiki所述Wayland需求 https://wiki.archlinux ...

环境： macOS 12.2.1 gpg (GnuPG) 2.3.4 (homebrew) 与Keyserver进行连接操作时，无论如何都会返回Network unreachable错误。 Google后，在lists.gnupg.org上找到前人相同的问题反馈，得到解决方案。错误原因未知，大概和网络连接模式(tor)有关。 解决方案编辑~/.gnupg/dirmngr.conf配置文件(无则创建)，添加： 1standard-resolver 重启后生效。

定义了一个简单的基于TCP的面向报文的协议。大致组成就是报文起始标记，协议版本号，载荷类型，载荷，报文结束标记。 我的业务场景是使用protobuf(Google Protocol Buffers)进行客户端与服务端之间通信的数据封装。正如pb文档所说，pb没有提供多信息流式传输的支持，而如果使用如TCP（面向流的协议）就不能直接传输pb了。所以需要自己定义一个协议来进行信息分隔。 样例代码注：代码位于gist.github.com，如果无法加载样例代码，请手动点击链接访问。

最近在学习OSTEP这本书，留个课后习题笔记。 Homework(code):chapter cpu-api 8. Write a program that creates two children, and connects the standard output of one to the standard input of the other, using the pipe() system call. Code:123456789101112131415161718192021222324252627282930313233343536373839404142434445464748#include <stdio.h>#include <unistd.h>#include <stdlib.h>#include <string.h>int main(){ int pi[2]; int p = pipe(pi); // create pipe if (p < 0) { ...

重载左右位移符号用于iostream。 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859#include<iostream>using std::cout;using std::cin;class Vector {public : explicit Vector(int size = 1) { this->len = size; v = new int[size]; } ~Vector() { delete v; } int &operator[](int i); friend std::ostream &operator<<(std::ostream &, Vector &); //declare friend frie ...

压缩炸弹在一些攻防场景下可能有一些意料之外的用途 压缩炸弹生成工具：https://github.com/CreeperKong/zipbomb-generator 已知一个压缩炸弹bomb.zip 已知一个需要混入其中的文件，flag 查看zipinfo 目标就是将属性值做到一模一样，这样就不容易被发现。 先修改文件的修改时间 1touch -d "1982-10-08 13:37:00" flag 将flag混入bomb.zip中 1zip -kgjX bomb.zip flag 后记 k代表使用MS-DOS模式/FAT。 g代表在原来的基础上添加文件（末尾添加），而不是重新生成压缩包，不然就会导致压缩炸弹体积变大。 j代表不包含文件的路径 X去除文件extra属性以实现zipinfo中的”b-“ defN 需要在flag中填充一些重复字符，以使用哈夫曼编码，当然，文件体积相似也挺重要，最好填充一些相同字符，将体积填充到与其他文件相同。 zipinfo中的两字符标识如 b- tx bx 需要构造好文件内容，b代表binary，文件中有一些 ...

近期运维一台服务器(Dell PowerEdge R910)，发现没有服务器健康监控面板，运维十分痛苦。于是打算安装Dell官方提供的服务器管理工具。OMSA: Openmanage Server Administrator;PVE: Proxmox Virtual Environment。 原理？安装前的说明。OMSA在Dell官网可以很容易下载到，不过只提供了Windows版本和Redhat(CentOS)版本，而且官方说法，新版OMSA不支持R910（我不信邪），大概是Dell懒得做适配和维护。 网上有许多PVE6.x/Debian10的OMSA的安装教程了，我也就是站在前人的基础上，做个升级的操作。 安装过程就是使用Dell EMC OpenManage Ubuntu and Debian Repositories（官方）源，安装OMSA，不过由于OMSA比较新的版本没有适配Debian，使用这个源（等于使用Ubuntu的源），得事先处理一些依赖的问题。 注：虽然在Debian使用Ubuntu源十分野蛮，不过重点在于结果而不在于过程，只是利用到了这个源的便利性，安 ...

CentOS马上要退出历史的舞台了，能换Ubuntu就换Ubuntu吧…. 为啥我要维护这老CentOS服务器 :( CentOS6不能使用docker Build出问题（在其他电脑上可以build）。官方源docker版本太低。 network无法访问。CentOS的内核版本古老，容易出问题。 解决方案CentOS6早已停止维护，就没啥可说的了。后面两个问题还是可以挽救。2可以通过使用docker-ce源解决。3可以通过更新内核+重启解决。 但是下面还是得额外讲一下问题3的解决办法，更新内核生效需要重启服务器，对于生产环境的服务器并不可以随便重启。 问题3解决方案特征：使用host模式没有问题（必然）。但是使用bridge模式的network，宿主机不能ping通容器，容器也不能ping通宿主机（因特网就更加不可能），但是同个network下的容器可以互相ping。 如上，这是CentOS的内核版本问题。这里讲述的就是不更新内核修复问题的办法。 重建网卡因为内核中的网桥模块加载失败，众所周知docker创建bridge模式的network会创建一个网桥（与服务器的网卡NAT转 ...