# IA32 plugin, ver. 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 构建绝对 URL，以供类似 app.launchURL、document.submitForm 或 app.media.createPlayer 等 API 使用时，如果 baseURL 看起来是一个 UTF-16BE 字符串，则在执行拼接时，相对 URL 也会被视为 UTF-16BE 字符串，尽管它实际上是一个 ANSI 字符串。
这可能导致越界读取访问。另一方面，在分配内存来容纳目标缓冲区时，相对 URL 被"测量"为 ANSI 字符串。如果发生 OOB 读取，这当然是不够的。（字符串加上填充整个堆块的 NULL 终止符）。
这意味着什么？
它通常会导致崩溃，偶尔会覆盖 ArrayBuffer 的 byteLength 为 0xFF。
如有问题，请随时在 Twitter 上联系我：https://twitter.com/Zeusb0x
PDF 文档目录将有一个 URI 条目，它包含一个指向字典对象的间接引用。该字典对象又有一个 Base 条目，即实际的 baseURL。它很可能以十六进制表示，并以字符 \xFE\xFF 开头。（参见 PoC）。幸运的是，这是在普通、非特权上下文中更改文档 baseURL 的唯一方法。尝试从 JavaScript 中执行此操作将引发安全异常。