# IA32 插件，版本 2020.013.20074。
char * __cdecl FUN_2581894c(char *base_url,LPCSTR rel_url)
{
............................................................
............................................................
if ((base_url != (char *)0x0) && (rel_url != (LPCSTR)0x0)) {
if ((*base_url == -2) && (base_url[1] == -1)) {
iVar6 = bytes_len(base_url);
pcVar7 = base_url + iVar6;
pcVar8 = rel_url + 2;
do {
do {
cVar3 = *pcVar8;
pcVar1 = pcVar8 + 2;
*pcVar7 = cVar3;
pcVar2 = pcVar7 + 2;
cVar4 = pcVar8[1];
pcVar7[1] = cVar4;
pcVar7 = pcVar2;
pcVar8 = pcVar1;
} while (cVar3 != '\0');
} while (cVar4 != '\0');
}
else {
lstrcatA(base_url,rel_url);
}
return base_url;
}
.............................................................
.............................................................
}
当基于 PDF 文档的 baseURL 构建相对于它的绝对 URL，并用于诸如 app.launchURL、document.submitForm 或 app.media.createPlayer 等 API 时，
如果 baseURL 看起来是一个 UTF-16BE 字符串，那么在执行拼接时，相对 URL 也会被当作 UTF-16BE 字符串处理，尽管它实际上是一个 ANSI 字符串。
这可能会导致越界读取访问。另一方面，在分配内存以容纳目标缓冲区时，相对 URL 被“测量”为 ANSI 字符串。当然，如果发生越界读取，这显然是不够的。（字符串加上 NULL 终止符填满整个堆块）。
这意味着什么？
它通常会导致崩溃，偶尔会将 ArrayBuffer 的 byteLength 覆盖为 0xFF。
如有疑问，欢迎通过 Twitter 联系我：https://twitter.com/Zeusb0x
PDF 文档目录会有一个 URI 条目，其中包含对字典对象的间接引用。该字典对象又有一个 Base 条目，即实际的 baseURL。它很可能以十六进制表示法呈现，并以字符 \xFE\xFF 开头。（参见 PoC）。幸运的是，这是在普通、非特权上下文中更改文档 baseURL 的唯一方法。尝试通过 JavaScript 执行此操作将抛出安全异常。