无法理解此程序集x86代码

问题描述

我很困惑为什么“ sub_18054DFD0”功能使用“ crypto \ rsa \ rsa_ossl.c”的地址作为参数而不使用它。（ “ crypto \ rsa \ rsa_ossl.c”是openssl api库中的文件。）
我想弄清楚它是否调用了rsa_ossl库中的函数？

.text:00000001805BF4E7 loc_1805BF4E7:                          ; DATA XREF: .rdata:0000000180902990o
.text:00000001805BF4E7                                         ; .rdata:00000001809029A0o ...
.text:00000001805BF4E7                 mov     [rsp+28h+arg_50],r15
.text:00000001805BF4EF                 call    sub_1805AF500   ; STR: "crypto\bn\bn_ctx.c"
.text:00000001805BF4F4                 mov     rcx,rsi
.text:00000001805BF4F7                 call    sub_1805AF3D0   ; STR: "crypto\bn\bn_ctx.c"
.text:00000001805BF4FC                 mov     rcx,rsi
.text:00000001805BF4FF                 mov     r15,rax
.text:00000001805BF502                 call    sub_1805AF3D0   ; STR: "crypto\bn\bn_ctx.c"
.text:00000001805BF507                 mov     rcx,[rbx+18h]
.text:00000001805BF50B                 mov     rdi,rax
.text:00000001805BF50E                 call    sub_1805614B0
.text:00000001805BF513                 add     eax,7
.text:00000001805BF516                 mov     r8d,100h
.text:00000001805BF51C                 cdq
.text:00000001805BF51D                 and     edx,7
.text:00000001805BF520                 add     eax,edx
.text:00000001805BF522                 lea     rdx,aCryptoRsaRsa_o ; "crypto\\rsa\\rsa_ossl.c"
.text:00000001805BF529                 sar     eax,3
.text:00000001805BF52C                 movsxd  rbp,eax
.text:00000001805BF52F                 mov     rcx,rbp
.text:00000001805BF532                 call    sub_18054DFD0

进入功能“ sub_18054DFD0”：

.text:000000018054DFD0 sub_18054DFD0   proc near               ; CODE XREF: sub_1804FE630+42Ap
.text:000000018054DFD0                                         ; sub_1804FFAE0+AAp ...
.text:000000018054DFD0                 mov     eax,28h
.text:000000018054DFD5                 call    sub_180670B80
.text:000000018054DFDA                 sub     rsp,rax
.text:000000018054DFDD                 mov     rax,cs:off_18091E640
.text:000000018054DFE4                 test    rax,rax
.text:000000018054DFE7                 jz      short loc_18054DFFC
.text:000000018054DFE9                 lea     r9,sub_18054DFD0
.text:000000018054DFF0                 cmp     rax,r9
.text:000000018054DFF3                 jz      short loc_18054DFFC
.text:000000018054DFF5                 add     rsp,28h
.text:000000018054DFF9                 jmp     rax
.text:000000018054DFFC ; ---------------------------------------------------------------------------
.text:000000018054DFFC
.text:000000018054DFFC loc_18054DFFC:                          ; CODE XREF: sub_18054DFD0+17j
.text:000000018054DFFC                                         ; sub_18054DFD0+23j
.text:000000018054DFFC                 test    rcx,rcx
.text:000000018054DFFF                 jnz     short loc_18054E008
.text:000000018054E001                 xor     eax,eax
.text:000000018054E003                 add     rsp,28h
.text:000000018054E007                 retn
.text:000000018054E008 ; ---------------------------------------------------------------------------
.text:000000018054E008
.text:000000018054E008 loc_18054E008:                          ; CODE XREF: sub_18054DFD0+2Fj
.text:000000018054E008                 mov     cs:dword_18091E638,0
.text:000000018054E012                 add     rsp,28h
.text:000000018054E016                 jmp     j_malloc_0
.text:000000018054E016 sub_18054DFD0   endp ; sp-analysis failed

编译器：MSVC
架构：x86-64bit
该文件是一个混合DLL，而这部分是C ++代码。

解决方法

这是CRYPTO_malloc

的论点

很容易看出，该函数将参数传递给malloc_impl，如果不是它本身，则传递给malloc。
OpenSSL（及其类似BoringSSL的分支）使用此间接方法来增强malloc，请参见this

crypto \ rsa \ rsa_ossl.c 字符串是 where 您的 first 代码块中的函数来自。
由于OpenSSL是开源的，并且具有源文件名信息，因此很容易查明您正在查看的代码：

inside rsa_ossl_private_encrypt是在 crypto \ rsa \ rsa_ossl.c 中定义的。

之所以会这样，是因为有三个对“ BN函数”的调用（我想是一个很大的数字），其中两个是相同的，以及对“内存分配函数”的调用。 一个可能被分配的内存计算抛弃了，特别是可以搜索这些常量，但是如源所示，它们是由内联宏BN_num_bytes完成的，因此搜索那些常量（即256 ，7、8及其所有其他数字）都不会给出任何内容。

如您所见，sub_18054DFD0处的函数为OPENSSL_malloc，它仅需要一个参数。

OPENSSL_malloc将传递OPENSSL_FILE（as this doc pod says,it's just an alias for __FILE__）作为CRYPTO_malloc的第二个参数。
它还将行号作为第三个参数传递，在您的情况下为256（r8d的值）。我的人工分析发现该呼叫在下面几行，这可能是由于版本不同所致。

这些内存分配例程跟踪分配调用者的文件和行号，以简化内存泄漏和损坏的调试。
如果没有像Valgrind或DrMemory这样的工具（用于Windows），确实很难确定由于内存损坏而导致的错误，所以这很有意义。

,

sub_18054DFD0似乎是内存分配调用。如果未在j_malloc_0内存位置中指定替代功能，它将使用默认功能（cs:off_18091E640）。

上面的代码块将加载该值，检查它是否不是NULL，检查它是否指向该函数（cs:off_18091E640，这将创建一个永无止境的递归调用），然后调用重写

如果任何覆盖检查失败（无覆盖或循环引用），则检查内存分配大小是否为0。如果为0，则返回立即数nullptr，否则流传递到{{1} }。

覆盖函数或j_malloc_0都可以使用j_malloc_0寄存器值（可能是分配诊断的一部分）。