V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  acess  ›  全部回复第 5 页 / 共 113 页
回复总数  2245
1  2  3  4  5  6  7  8  9  10 ... 113  
@codehz 说实话经你这么说我昨天也感觉有点不明白了,因为回头看 weishu 的讲解里很强调 5ms ,但好像……这个 5ms 是对[同一个进程组]反复追杀时的歇息间隔,而如果我没理解错,被杀掉的这一组已经没办法做出什么反应了,是监视着它们的,受到文件锁关联的[另一组进程]立即可以感知到兄弟阵亡并马上反应……那么,还没被追杀波及到的[另一组进程]反应时间还是 5ms 吗?想到这里我就感觉有点奇怪,但我也太懒了所以没有继续深究(逃
@tool2dx 诶我这边感觉,之前看过 weishu 的博客讲解,现代 root 方案本来就是类似 ssh 到本机那样的“远程 root”,而并不是 app 自己的进程 fork 出来的


@kkocdko 啊呀别感谢了,今天发现很多地方我都疏漏了,比如 Android12 之后,Android12L 其实就已经引入了一个设置参数来完全关闭幽灵进程杀手,只不过是这个参数不在开发者设置 UI 里,只能通过命令行设置,Android14 只是在开发者设置 UI 里新增了设置项(而且和之前的命令行设置不完全一样,命令行设置可以永久保存,开发者设置这边则是如果关闭了开发者设置就会重置)。再比如 Android5 以前其实只要 fork 出去,force-stop 甚至完全不会杀到你,是 Android5 才开始管到 fork 出去的原生进程,等等……

@zhenjiachen termux 开发者提到过,杀的时候看 app 进程的 oom_adj ,还看进程自己什么时候启动的,启动早运行久的优先杀。而且杀进程动作触发也不是非常频繁。所以按我理解的话……如果只是短暂启动执行一个命令马上就退出那被杀几率应该非常小,但也不好说,因为系统默认全局所有 app 加起来只允许 32 个幽灵进程存在,如果别的 app 在搞事,正巧在你执行命令的时候开了一堆幽灵进程出来跟你抢,这个几率也不严格是 0 吧。
@codehz https://weishu.me/2020/01/16/a-keep-alive-method-on-android/

重点貌似不是进程多让系统杀不过来,而是……

杀一个进程的时候另一个能立即感知(通过文件锁实现);

然后第二个重点是在 5ms 内完成重启。

非常令人意外地,因为系统每执行一轮追杀就要歇息 5ms ,所以另一个进程居然还享有 5ms 时间能够做出反应。只要它在这 5ms 之内能通知 binder 完成重启复活,然后因为系统只重复追杀 40 次(所以也不是“持续杀 5 秒”而是只有 200ms ),40 次追杀都逃过了系统就不再继续追杀了,等于放过。
(啊啦坏了,一处 W^X 我写错成 R^X 了,捂脸)
这件事其实还让我想起来很多年前 @madeye 接受的一个 PR ,在 shadowsocks-android 里引入了进程被杀自动重启的 GuardedProcessPool 机制:

https://github.com/shadowsocks/shadowsocks-android/pull/594

那个时候好像认为这属于 vendor-specific bug (?明明是故意的)

现在看其实 ss-android 一直以来都在用幽灵进程支持自己的核心功能……(天
206 天前
回复了 ALLROBOT 创建的主题 Android 有没有非 Root 的 Android 自动化程序?
autojs pro 我记得是作者自己杀死了这个项目,理由是被黑灰产利用

(旧版 autojs 开源,不像 pro 闭源,并且有衍生版,比如 hamibot ,大概还有楼主提到的)
呃这个不止是下载回来这么简单。

bitcoin core 全节点下载的时候,一边下载,还一边验证区块内容,一边还在扫描区块内容以从中找出和你钱包有关的交易,从这些交易才计算出你的钱包最终余额。

你如果从外面下载回来塞给 bitcoin core ,因为下载回来的区块就只是区块,没有完备的索引信息所以不能直接从地址快速查到相关交易(这个只有类似 eletrum 服务器或者区块浏览器服务器才能构建,需要消耗几倍磁盘空间),那还是得粗笨地扫描区块才能把你钱包的信息恢复出来,看你机器性能如何了。

总之绕一圈下来你还不如老实用 bitcoin core 自己一边下载一边扫了事。
219 天前
回复了 acess 创建的主题 硬件 SSD 会消灭 HDD 吗?
@HarveyLiu
@wangyuescr

HDD 和 SSD 到底哪个可恢复性更差我感觉也许都不好说,就算是 SSD 确实更差,现在我看见的情况并不是一旦坏盘就 100%全丢全完蛋,其实也有部分或全部找回的(包括漏电严重,读速极慢每秒只有几 mb 甚至几百 kb ,看了 homolab 的科普里提到 ldpc 可以回退至软解码模式,软解码需要循环不定次数的很多次,纠错力强但特别慢发热高)
219 天前
回复了 acess 创建的主题 硬件 SSD 会消灭 HDD 吗?
@wangyuescr 挖个坟,b 站关注了小飞机挺久,其实 SSD 也可以数据恢复的,有不少是电路故障可以直接修好,还有主控读不出来或者固件挂了的我记得也有可能解决,甚至印象里还有厂商的 ecc 编码方式已知,可以用 pc3000 软件解码出来。

不过确实也有不少完全恢复不了的,比如颗粒完全挂了一点读不出来的,还有主控“加密”了(不知道是具体是密码学加密密钥读不出来,还是说只是编码方式等技术细节未知,总之就是搞不了)
我印象里好像有次试了某厂商魔改的内录 API 还实际没工作……也可能记错。
Android 6 据说是只要 root 就可以,神器 SCR Screen Recorder ,可以实现最理想的插耳机播放+内录+录制麦克风,比如你录游戏:插耳机不会外放,所以内录得到的游戏 BGM 和音效是纯净的,在此之上正好可以再混入你的语音,要么是现场开黑要么是实时解说。

Android 7 开始就很难了,AOSP 原味系统里特别难几乎不可能。都不知道 google 咋想的,是不是跟唱片公司版权流氓有一腿。搞得网上一大片视频要么全损音质要么聋的传人,合理的需求没办法满足,真是。

我当时专门寻找尝试过,只有 ScreenCam 能内录(另一个好像叫 tornaco 印象里我这边试过不行),录制时还不能同时播放很难受,还需要 magisk 模块,看上去是覆盖了系统内部的混流配置才行。

AOSP 毕竟开源所以厂商可以改出来一个接口实现内录但这存在问题,一是不标准不通用二是刚刚开头提到的插耳机麦克风+内录这种精细化的配置未必能实现。

后来是 Android 10 还是几来着终于有内录 API 了但 app 可以拒绝内录,而且好像还是不能 Android 6 时代 root 一下就有的插耳机麦克风+内录

再后来好像 API 又改进了终于能麦克+内录了但我好久没关注了记得不太清楚了
222 天前
回复了 busier 创建的主题 硬件 HDD 数据销毁软件的反复覆盖是智商检测么?
另外 CMR 机械盘上基于文件的覆写我记得也是相对可靠的(呃前提可能是,像,文件没有被缩短过?)

不然为啥 coreutil 里都有个 shred ,就是因为文件层面的覆写会对应到 LBA 乃至最终物理层面的覆写
222 天前
回复了 busier 创建的主题 硬件 HDD 数据销毁软件的反复覆盖是智商检测么?
@busier 哦 HDD 啊,我这也是歪楼了……那这个 HDD 就是比较经典的 CMR 硬盘,也就是可以直接覆写,没有翻译层(也不考虑重映射坏扇区)

那我感觉你说的可能有道理,这个有点不可知论,因为至少,咳咳,我并不知道主控,或者说相对简易可行低成本的黑客手段能不能接触到非黑即白的 0/1 之外的数据(比如把信号线飞出来接到高频示波器上)

考虑到主控固件至少有被比较容易地反编译的可能,那还是得考虑这方面风险的吧,说不定主控固件层面读到的就不是 0 或 1 而是 0.2 、0.3

商业化的数据恢复大概直接用的 PC3000 这种成品软件,他们自己可能不会做逆向工程乃至没能力逆向工程但据此就说“这种技术在民用层面不存在”,恐怕不太充分


还有就是楼上提到过的,多覆写几次成本也并不太高也就是多耗时间多耗可忽略不计的一点点电费,顶多再加上中途把盘写坏导致丧失二手回收价值的一点点风险……

就算本人可能没什么真正的秘密,他就是觉得 cool ,why not ,那

只能说各自保留观点了,你觉得他是老烧神棍是老中医,他乐在其中捂住耳朵不听不听,反正你也没办法(

我记得 FDA 对替代医学的看法也是,do no harm ,至少无害,只要在无害随你怎么折腾去
223 天前
回复了 busier 创建的主题 硬件 HDD 数据销毁软件的反复覆盖是智商检测么?
啊刚刚又想起来一件事,Bitlocker 设计上并不是推荐纯软件模式的,它尤其是特别依赖 TPM ,你不给他 TPM 他虽然也工作但很明显是不情不愿的[doge]。

然后 bitlocker 存在一个“暂停保护”模式,我印象里是把 VMK 明文直接写到盘上了。

之所以会有这个模式,其实就是因为考虑 TPM 跟固件绑定,可能升级个 BIOS 说不定 TPM 就重置了,然后就不能自动解密了(这个时候就全指望恢复密钥也就是数字密码了,但这个密码很长输入起来很麻烦)

为了优化用户体验,我印象里系统自动更新时,是有可能自动让 bitlocker 进入暂停保护模式的。

于是,在我个人看来,这个时候是可能存在明文 VMK 被主控翻译层遮蔽而没能抹除销毁的隐患的。

但我一直都很疑惑,好像真正的专业人士,学术界,或者微软自己,可能更早会关注到这个问题?但我大致在网上搜过几次没搜到什么相关的内容。

(抱歉 at 一下我心目中的一位佬 @geelaw
223 天前
回复了 busier 创建的主题 硬件 HDD 数据销毁软件的反复覆盖是智商检测么?
很多年前我记得也有刷到过新闻报道了一项研究,是讲 U 盘的

毕竟 U 盘里有 FTL 翻译层

记不太清了,大致印象里不是理论分析而是实际上跑到当时的市面上买了好几种 U 盘做实验的,结果就是覆盖很多次可能都还有一些数据残留在 LBA 层不可见的,呃我也不知道叫什么,大概就是类似备用区和 OP 空间的概念
223 天前
回复了 busier 创建的主题 硬件 HDD 数据销毁软件的反复覆盖是智商检测么?
@ysc3839 具体不太记得了,但好像也有搬板的操作,还可以上测试架……哦还有,pc3000 软件我记得还有根据不同的 ECC 编码方案重组功能。

如果是「当前/原厂/原配」主控跟闪存颗粒绑定,那确实 blkdiscard 一下就够了——但这个前提未必成立,我大致印象里,光是 PC3000 软件可以解码 ECC 重组数据这个事实就很难讲“民用级别数据恢复不能绕开主控”了。

读取数据必然要经过一个角色类似主控的设备来“驱动”闪存芯片,在这个意义上当然还没看见像电子显微镜一样不同的高科技手段去直读,但绕开「原有」主控这个貌似并不是不可能的。

所以我个人觉得 blkdiscard 本身肯定不够可靠,我印象里 trim 命令本身也有可选的一个 secure 选项,所以需要执行类似 ata security erase 这样的命令才比较可靠,因为这个至少明确要求厂家去按照安全擦除的要求去实现。

虽然退一步也可以说,厂家有没有老实实现,有没有偷工减料,有没有 bug 甚至埋后门也不好说。这种情况下反复覆写是一种退一步情况下的缓解措施。

嘛感觉真要是数据保密的要求远大于盘本身的经济价值,那大概还是得物理销毁。


哦突然还想起一件事就是 bitlocker 可以选择纯软件加密,只要 FVEK/VMK 不泄漏,那么销毁主密钥即可实现销毁数据,同时也不用物理销毁硬件,还可以回收。
1  2  3  4  5  6  7  8  9  10 ... 113  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1461 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 17:11 · PVG 01:11 · LAX 09:11 · JFK 12:11
Developed with CodeLauncher
♥ Do have faith in what you're doing.