这两天搞了一下 yu-ris 的 ypf 封包,这里做个简单的记录。
ypf 主要用了 zlib 进行压缩处理。包头里有文件数量和数据区起始地址等信息。文件索引表里包含了文件的偏移、压缩后长度和原始长度等基本信息,文件名则是经过取反后存储的。文件索引表非定长。
这两天搞了一下 yu-ris 的 ypf 封包,这里做个简单的记录。
ypf 主要用了 zlib 进行压缩处理。包头里有文件数量和数据区起始地址等信息。文件索引表里包含了文件的偏移、压缩后长度和原始长度等基本信息,文件名则是经过取反后存储的。文件索引表非定长。
之前处理了一个 bug,软件在一些使用场景下会发不出 udp 包,排查之后发现是调用 sendto() 函数成功,然而使用 wireshark 却抓不到 udp 包。
然后在排查过程中查看 arp 表时,结果意外发现居然有两张网卡是被设置成同一个网段 的 ip 了,摔啊!
于是看了一下路由表,发现果然是未使用的网卡 B(192.168.2.56)的记录在网卡 A(192.168.2.204)之前,而设备是连接在网卡 A 上的。
这就导致通讯时系统会首先使用 B 来发送数据包,而当设备的 mac 地址没有被网卡缓存时,B 会首先发送 arp 广播包获取设备的 mac 地址。当然连在网卡 A 上的设备 C 是没法回应的,然后数据包会因为 B 没有目的 ip 的物理地址而发送失败。
另外当 B 的 arp 失败后会在 B 的 arp 表中生成一个该 ip 地址的记录项,指示该 ip 对应无效的 mac 地址(00-00-00-00-00-00),根据微软的描述,默认情况下该记录项会在15到45秒后刷新。在 B 的记录清除之前再发起通讯请求时系统会选择使用 A 发送 arp 广播,这时设备便能接收数据和正常通讯。否则当 B 中的无效记录被清除后会继续使用 B,通讯依旧会失败。
总结一下就是两张同网段 ip 的网卡,当两张网卡的 arp 表都没有对应的记录时,系统会根据路由表中记录的顺序选择第一个网卡进行通讯(启用、禁用网卡可改变路由表的记录顺序)。如果网卡的 arp 表中缓存了对应的 mac 则会直接使用相应的网卡进行通讯。
当然最好还是不要设为同一个网段……
——艾拉
首先还是要谴责一下奸商贩卖劣质内存条!
很多网友都吐槽剧情安排上有不够完善的地方,比如中途拐走玛莎的事件,安排地比较生硬,做了些多余的科普,颇有刻意送助攻的感觉。再说倒卖是为了研究本体然后换上高质量内存条逼死官方么……真要趁坏掉前卖出来黑一笔钱的话可操作性也太低了,除非买家真的不在乎有多少剩余使用寿命。另外司在射玛莎时(误)我真担心射中艾拉 _(·ω·」∠)_,还好看来是在光环笼罩下成功发动了贫乳回避的被动技,没出幺蛾子。
前半的剧情中艾拉由于自己寿命问题而对回忆采取十分消极态度,打算一直作为机器继续生活,不愿创造新的回忆。而在被司攻略后就逐渐展露出了各种原本的性格(实在是呆萌(///ω///)♪)。在第 10 集展现的全剧关键矛盾中,艾拉最终整理好自己的情绪,决定好好地面对司,渡过更有意义的剩余时光。
封包的结构比较清晰,只是其中的图像是经过压缩编码的。
图像分为两种,一种是文件标识为 “GE” 的单图文件,另一种则是文件标识为 “PGD3” 的差分文件。差分文件中含有一个单图文件的文件名,当引擎读取差分文件时会同时读取单图文件,解码后将两者进行混合。代码里还备有 “PGD2” 的分支,是 “PGD3” 的一个子集。不过这个游戏里似乎并没有该类型的文件,所以先不管了。
两种图像格式的结构
在看一篇木马的分析时看到里面提到木马会读取浏览器的用户配置文件,并对其中的密码进行提取和上传,于是就有了兴趣,想看看浏览器是怎么对密码进行储存的。
现在 chrome 要查看浏览器保存的密码时需要首先验证登录账户的密码了,但这样其实保存的密码还是不够安全的,因为这个认证可以直接绕过。下面来分析一下 chrome 保存密码的方式,以及如何对保存的密码进行提取。
在将我的东方弹幕游戏拖到 win10 虚拟机中运行时发现程序一运行就崩溃了,报了内存访问异常(0xc0000005),而且多运行几次现象也会不同,有时是直接崩溃,有时还能坚持到显示完启动画面,但进入游戏时还是会高概率的崩溃 – -b 。
于是挂上 windbg 看一下,发现断在了这里
0012da40 55 push ebp 0012da41 8bec mov ebp,esp 0012da43 8b4508 mov eax,dword ptr [ebp+8] 0012da46 0f2800 movaps xmm0,xmmword ptr [eax] 0012da49 0f2901 movaps xmmword ptr [ecx],xmm0 ; <--- 0xc0000005 0012da4c 0f284010 movaps xmm0,xmmword ptr [eax+10h] 0012da50 0f294110 movaps xmmword ptr [ecx+10h],xmm0
Copyright © 2024 Re: Memory. Powered by love.