2020年7月

我不是在看WireGuard吗,怎么跑到这里来了

在学习WireGuard的时候,发现其中用到了ip rule命令来根据数据包的fwmark属性匹配不同的路由表。因为觉得比较神奇(和方便,作为路由器来说),所以就选择了深入一步进行了解。在阅读了一些博客中记载的简单配置实例后,将在Linux中进行路由配置的大致流程记录如下:

需要用到的工具有两个:ipfilterip。大致流程是首先使用iptablesmangle模块(修改网络数据包,可应用于QoS等场景)在系统内部对数据包进行识别和分类(进行标记),然后使用ip rule命令根据iptables对数据包进行的分类标记,选择对应的路由表进行合适的包发送操作。

https://kknews.cc/code/gaag6bl.html

因为mangle的处理是优先于natfilter表的,所以相依数据包到达之后先打上标记,之后再通过ip rule规则,对应的数据包使用相应的路由表进行路由,最后读取路由表信息,将数据包送出网关。

突然发现没啥要写的了,就这样吧

(咳咳,星之梦,eden*,塑料内存条,ATRI,奇怪的故事增加了)

这两天摸鱼快速打完了ATRI,现在感觉仿佛有那么一点。。惆怅的心情?

亚学家 亚学家.jpg
这图一定要放出来
555,写文的时候都晚上了,网友肯定都组团捞完回来了

也到某乎和贴吧上看了一下网友评价,觉得也和自己的感想在总体评价上一致,属于演技、逻辑、环境渲染表现良好,但是立意出发中规中矩的那种,结局就剧情中的现实意义而言算是还行的。不过由于剧本容量较小,不少网友认为水菜萌当了工具人来着= =我倒是觉得,还是那套说辞吧:若要说夏生和水菜萌两者有感情,剧中没有明确的剧情叙述;反之若要说没有,也可以辩驳说剧本里写不了一切。总之,什么观点自己喜欢就好,不必证明并强加于别人。

等什么时候steam发小绿票了去充值一下信仰吧

音乐评价也和其他人差不多,虽说算不上优秀的砖,但当作闲暇之时BGM还是足矣的。就我个人而言,绝大多数国产游戏(咳咳,反正我是还没见过那不存在的极小部分)和一部分国外游戏的BGM是做的真的8行。(可能也和游戏本身的设计有关吧)

然而OST 10月才发售。为了听歌我还得开个游戏?要是充值了的话我还能挂个游戏时长
重点是这玩意不稳定,下的DARKSiDERS的版本,只要闲置时间过久,程序就会自己停止工作= =
然后想法只有一个,那就是传统艺能——拆包了。

KrKrExtract的界面过于难受,没有GUI预览,对于还在使用SMR磁盘的用户来说更加难受了(体会过硬盘灯常亮,甚至闪都不闪的感觉吗);而GARbro好是好,缺陷在于针对(似乎只有KrKr引擎的?)不同游戏的特殊解密方式都隐藏在了一个看似加密了的文件Formats.dat中。这个文件基本上都是由原作morkt更新的,然而上一次还在去年年初= =。ATRI的xp3文件也被加密了,可以看到文件名称,但是无法读取内容。然后运气好,这次看到有佬在issue区放出了ATRI所使用的加密算法CxEncrypt的关键参数,估计就差一个把参数整合进软件的工作了。

初步看了一下代码。似乎Formats.dat是一个使用Deflate算法加密了的C#序列化对象,然后添加了一个自定义头,在主程序开始运行时加载。至于具体用法,等接下来有时间我再补充吧。

什么叫数据流失啊?(战术后仰)

在粗读《cGAN-based Manga Colorization Using a Single Training Image》的时候,发现里面的漫画画风还行,打算找一下来源,结果以图识图找出来全是这篇论文的引图

哈哈哈 失礼了.jpg

好在作者给出了关键词“Monster Beat”,然而拿着这玩意直接去搜,啥都没有

然后考虑到11区的人普遍脑洞偏大,把这名字直接转回片假名「モンスタービート」,总算是找到了一丝端倪:这是一个在2016年就已经关服的游戏。

接下来就是要借助众位肥宅的力量了,找到游戏的攻略网站,顺藤摸瓜找到Twitter和官网——当看到Twitter上宣传漫画的那一张横幅图的时候,我就确信,已经「破案」了。

接下来要做的事情就是找到原漫画。直接访问官网的话,网站早就卖掉了,到archive.org上看,网站还被转手了多次,hhh

我贴
https://web.archive.org/web/20160529154912/http://monsterbeat.net/special/index.html

通过这个网址,就可以感受一下什么叫做数据在不经意间的流失了。

升华一下主题,人生走不了回头路,也没必要走回头路——能走的路太多了,唉。

caffe就是个阴间项目。我生气了。

Windows下的配置太恶心,根本没法用,编译出来还能加载DLL失败。

唉,不想多说了。Python也是个阴间玩意,说是说DLL加载失败,可就是打死都不说是哪个。几十年了,没人管管的吗?

我为什么不管?这是我专业吗?要是能靠这吃饭,我早去考虑这个问题了。。

总而言之,还好有人提供了工具: https://github.com/lucasg/Dependencies

这个工具可以解析pyd文件的DLL依赖,感觉和ldd很像。(但是有机率崩掉?)
虽然问题没有直接解决,但是通过这个工具可以对pyd的内部依赖进一步了解,为解决问题提供可能,

主体流程按照文档来就行,先编译Boost.Build,然后用生成的b2来编译剩余的部分。

主要是在编译Boost.Python遇到了问题。虽然在编译时传入--build-type=complete参数也包含了对Python模块的编译,但是仔细阅读文档可以发现,这个complete指的是尽可能完整,也就是说,如果某些模块编译出错了,b2会放弃编译该模块,而不是发出严重错误的警告——“反正我是尽力而为嘛”。恰好在我的情景下,Boost.Python就是其中之一。网上对于如何编译这个库的讨论很少,在StackOverflow上也只是找到了少量的讨论,感觉似乎要么是没人整这些东西,要么人人都是专家= =

后来发现在Boost的文档中提到,有一个配置文件叫user-config.jam,在这里进行Python的配置。先贴一个我的配置:

using python
    : 3.6
    : C:\\Program\ Files\\Python36\\python.exe
    : C:\\Program\ Files\\Python36\\include
    : C:\\Program\ Files\\Python36\\libs
    : <toolset>msvc
    ;

但是这个配置文件的位置有讲究,说是要放在家目录下(参见 https://boostorg.github.io/build/manual/develop/index.html#bbv2.overview.configuration )。如果在Windows下不想配置家目录,那么就需要使用--user-config=参数来显式指定配置文件。有些教程说将这个文件放在编译的根目录下也行(未经尝试)。

编译完成以后,目录结构还是保持了类似源文件的文件夹结构,因而若是要一个个手动添加库文件可以说是一项繁重的工作。这里放一段把所有动态/静态库文件提取出来,放在同一个文件夹下的Python代码片段供参考:

import shutil
import os

dest = './lib'
try:
    shutil.rmtree(dest)
except Exception as e:
    pass
os.makedirs(dest)

def explore(prefix: str):
    if prefix == './lib':
        return

    if os.path.isdir(prefix):
        entries = os.listdir(prefix)
        for entry in entries:
            explore(prefix + '/' + entry)
    elif prefix.split('.')[-1] in ['lib', 'dll'] and ('vc142-mt-x64' in prefix or 'vc142-mt-gd-x64' in prefix):
        shutil.copy2(prefix, dest)

if __name__ == '__main__':
    '''Extract all boost libraries. @Esper'''
    explore('.')

将该代码片段放在libs目录下执行,即可在名为lib的新子目录中找到所有提取的库文件。同时,对于explore函数中的某些判断条件需要进行合适的修改,比如vc版本,编译条件或者系统位数等,还请读者根据实际情况调整。