我上一个 GPG Key 已于 2019-12-31 过期并且已经 revoke。新的 Key 将于稍后生成。

GPG Key 指纹 200A B88E BD4D D442 9D0F AD9C 44FF AF06 9A80 6DED

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBF4XrEsBEACiMdVNLu1SfOm5h3zob1GM5QZ0eV8ocWdF2eTZ2eA8M3fD49/6
F5fpRwaUBo8V1KkGko3WHyrAL5I+O32E5i5nwaA1BQ1nCv7Jj67r+p4XlhkBjb/i
yXe/fzmIsBZ32B58DF7bGnTqxUzUzHVf1lOEMAS/g/RSNNYYVsQkZ3/kVPDNs5q+
aRaoJrxW290pGFZJrpP4rlTzFlUqAjnEtRK2CkUmNirFTd+vYubX0dgbMdPnZ/DK
x1PdVgbfWlfBlU2IzngERLexUhX4+bfo4LyWHieh6nDK6w0FcRZfNp2J8F7LSH+9
093aFCLcIFmZ/WP+g2tTdzdC3ZjiqxSeJ8xiHwVJfHLB1KjkY4yXJi5yPhgKA+HT
FqjOtD7A5sN5M14jdCx297LSh7sVGBkq73Xxar8KMh4gRtTGpiJ4b152AXxdlOpB
di2col8e8gT2Xw19M7QZjo5iJLdc98K7J6HwMVugUaVJavctV268Qr5XztXBFi5q
1HOMJhPJsk/OpiQhZOlOVUWwEU5j8IKzHpOe7zDJs+7cfAxn7tizeB+wU8B3kdAt
X4O6DwaPQt8BTf7DwrPf6ktiK5xXI18lcg2t44xrIC8Ani/gM5hc3r5Pme0GMyHK
PxGwElxBgtk6LSXvJ/+9chiQPo09WaZJ06DH9mVRnjFpFQsLWIszVm5QawARAQAB
tC5SaWNoYXJkIFl1ICh5c2MzODM5KSA8eXVyaWNoYXJkMzgzOUBnbWFpbC5jb20+
iQJSBBMBCgA8FiEEIAq4jr1N1EKdD62cRP+vBpqAbe0FAl4XrEsCGwMFCQlmAYAE
CwkIBwQVCgkIBRYCAwEAAh4BAheAAAoJEET/rwaagG3tF0MP/0W2LJDEbzJaDrEK
WO0+KN6UBphXDmFYff0q1BRDBPVVZ8CArOFY4j18LLB8YKm+PEkapcbvQ4DJlk9e
YJswMaNCZkt+Hi7Aj9P3dOo2eIVA1cIvso6dAs/Ol9qiCv3/PA7ASmG6Kz5Qg1N8
L1cNGX4yws+UCnjZsGU1yhxu4c9YuD5E+EJUp5hYLM5KD7CZO6aK6ts5uEdU47Ck
x/eOWlPaOuUCYFSepqXDxstaPglJ2lfSYHkCGfFcqMwVvXWtd0lBOBuCBSyxcqey
KbMGKZ9vLY+shmdQupW0sHFt8JpWyh3D5LMcZZRUtVJfXW0+/3eeEplJl3Cmwq04
efrUEfx1e3nDCAi7GsQZS/9NH4P6hZfPgsRqyHceaob0aZg1pGwXXKjsN6ggq1wz
OCmXESdwam0K28xm0t8HOuDiwmrbikH1XcUm1vn9b5wZXj25TMhVD4eKohACxxdV
2EWRHsk0dvgB7oQYM5fjqRH1gWQF0qyXPGUqp8XOe7IWcgJRA3qPSm9y97CgPeM8
FYScSMk0vHW+sVyu9TDmRkCTDIlwD0GP8B/2VrQhWYhSJoWmYifBGeCfKJdIk9Zo
k5fmygTtTEnMdQdfmEmiwdSUCGyHpmLo5owOB+Imn0xLTHxst4bUv4Wt2zHQPX3Q
shCYdNz+tdylrprtNjo7l+jQlKv2
=Cs/L
-----END PGP PUBLIC KEY BLOCK-----

草，刚刚在分析 KeePass 如何实现复制时不添加到 Win10 剪贴板历史记录，发现用的是 WinRT 的剪贴板 API，里面有个选项可以控制是否添加到历史记录。
然后尝试逆向 WinRT API 的实现，发现最终是调用 OleSetClipboard 来设置剪贴板的，但是仍然找不到哪个参数控制的，于是往回找。发现 DataPackagePropertySet 有几个文档中找不到的 Property，其中一个是 CanIncludeInClipboardHistory，突发奇想去网上搜一下，结果……………………

微软的文档直接就有写……
To stop content from being included in Clipboard History, set the registered format as CanIncludeInClipboardHistory with a DWORD value of zero. (A DWORD value of one will include the content).
https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats

还顺便逆向了下 Windows.ApplicationModel.DataTransfer.Clipboard.ClearHistory，发现是 DCOM RPC 实现的，这个就别想着绕过 WinRT API 了。

OpenWRT 曝远程代码执行漏洞
https://www.solidot.org/story?sid=63387
「路由器发行版 OpenWrt 披露了一个远程代码执行漏洞，OpenWrt opkg 包中的一个 bug 会导致包管理器忽略库索引嵌入的 SHA-256 校验和，事实上绕过了下载 .ipk 文件的完整性检查。由于 opkg 包以 root 权限运行，对整个文件系统具有读访问权限，意味着 .ipk 包嵌入的恶意负荷能执行任意代码。开发者已经释出了新版本修复了漏洞。」

> Older versions of OpenWrt (e.g. OpenWrt 15.05 and LEDE 17.01) are end of life
and not supported any more.

我拖了很久的项目 OneDrive Directory Lister 已经完成了基本的目录列举和跳转下载功能，不过目前还不能用于生产环境。
这是一个使用 Node.js + express 编写的列举 OneDrive 文件的网站后端程序。你可能问为什么不使用其他现成的项目而要重复造轮子？因为我最初设想是用来白嫖各种免费的 Serverless 平台，我调查过 Google Firebase, ZEIT Now, Netlify 和 Heroku 这四个平台，都支持 Node.js。但是我似乎没有找到使用 Node.js 编写的同类项目，所以打算自己开发。
这个最初的版本可以进一步完善再发布的，不过还是觉得先公开出来接受评论比较好。目前网页界面是抄袭 nginx autoindex 的设计。

odl 0.1.1 已发布 (GitHub, npm)，修复了目录解析时无法处理反斜杠的问题 (ca10fcf)，以及处理了 OneDrive 文件不存在的情况 (fcd1696)。该版本应该没有安全问题，可以用于生产环境了。不过还未实现缓存功能，所以仍不建议用于生产环境。

OpenWrt 近期的一个投票结果出来了 https://lists.infradead.org/pipermail/openwrt-adm/2020-February/001316.html
你们感兴趣的可能有：
1.跳过 Linux 4.19 内核，下个版本将会使用 5.4 内核 (5.4 内核仅比 4.19 多了一票)
2.使用自建的 GitLab 平台托管代码
3.投票选出了新的 Logo

新的 logo 详细设计
https://openwrt.org/docs/guide-graphic-designer/openwrt-logo
预览图
https://forum.openwrt.org/uploads/default/a659bf50e40b935070b223e81f311c737ed257b0

The Microsoft Edge WebView2 control enables you to host web content in your application using Microsoft Edge (Chromium) as the rendering engine.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
草！Chromium Edge 统一 WebView 居然还成真了！

刚刚被 Windows 坑了，偷懒用 DialogBoxIndirectParam 创建对话框 (因为 CreateWindow 的话还得注册一个自己的类)，这个函数是你把窗口信息的结构体写好传进去就行，不过它支持两个版本的结构体，我没什么特殊需求就用旧版本的，结果一直失败。
然后发现如果自己 malloc 一块比较长的空间，并全部清零就正常了。很疑惑为啥要更长的空间，于是逆向+调试这个函数，发现它即使检测到了旧版本的结构体，还是会当成新版本去访问其中某个值，结果就是越界访问到了一些不知啥的数据……
解决方案是在后面加上一段 padding，全部清零，估计是没啥问题了。

刚刚在翻 ReactOS 代码时发现，当 Dialog 字体大小 (font point size) = 0x7FFF 时，会自动使用 MessageFont (可以理解为系统默认字体)。觉得可能是一个偷懒解决字体问题的办法，继续搜索发现了 Wine 的邮件列表中提到了这个 feature。然而实际测试时窗口不会出现，逆向代码发现 Windows 确实也会根据 0x7FFF 使用 MessageFont，继续跟踪下去发现问题似乎是创建子控件时失败了，删除所有子控件后能成功显示，但是这样的话就没啥意义了。
打算继续研究一下，看看是否有什么办法解决。

继续逆向发现，MessageBox 也使用了这个特性，但是却没问题，打算从这方面入手调查。

调试发现 MessageBox 传进去的数据是昨天提到的“旧版本”结构体，进一步测试发现改为旧版本的 Dialog 之后就能成功显示了。

考虑到大多数读者应该没了解过 Win32 开发，了解 Win32 开发的也希望获得更多细节，在这里解释一下什么是 Windows Resource Dialog，以及新旧版本的问题。
关于 Resource：直接翻译是“资源”，是 PE 可执行文件中一个可选的区段 (详情请自行搜索 PE 格式以及区段)，这个区段里面一般会存放 exe 图标等数据。不同数据是先按类型划分，再按 ID 划分，可以在这里看到系统预定义的类型。
从上面的链接可以看到预定义的类型中有 Dialog 类型，直接翻译是“对话框”类型。一般情况下 Windows 中要创建窗口必须调用 CreateWindow 手动创建，布局什么都得写代码，比较麻烦。但 Windows 还额外提供了 Resource Dialog (“资源对话框”)，通过编写 RC 脚本，编译时将这些脚本编译为对应格式的数据保存在资源区段里面，运行时调用对应的 API，系统会解析这些数据并帮你创建好窗口，布局什么的也可以借助资源编辑器来实现，可以省很多事。
而前文提到的“两个版本”则是两个版本的对话框模板，旧版本比新版本少了一些 (很不常用的) 字段，具体的结构可以在微软文档查到 (旧版本, 新版本)。