Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

Problem with Anti-Exploit and Adobe Acrobat Reader/DC

New Here ,
Mar 28, 2017 Mar 28, 2017

Recently we found a problem with our Anti-exploit and Adobe acrobat reader/dc where abnormally the program is closed when a documment is opened. We contact our support who investigated the problem and sended to us this document. I tried to talk with adobe support but they said that only payed products has support and what i can do is try to open a discussion to verify if has a way we solve this problem. Can anyone help on anything?  Is anyone of support interested in helping to solve this problem?

Below, the document.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

AcroRd32's hook point is set by its parent process (another AcroRd32). Before the user mode code starts, the hook points are already installed. In this hooking architecture, it might be interop with other user-mode injection techniques.


 

When TrendMicro DLL creates a thread inside AcroRd32's process, it will call some system API which is hooked by Adobe, for example, ZwOpenEvent/OpenEventW.

The hook handler is protected by C-Runtime's stack guard. If this call occurred before/during main thread initializing security cookie, this thread will trigger buffer overflow exception because the security cookie seed has been changed.


 

Analyze of adobe’s API hooking:

Anyone calls this hooked function (OpenEventW) will go to AcroRd32+0x14ac0 ( OpenEventW_Handler).


 

 

KERNELBASE!OpenEventW:

77881300 e96bed7089 jmp 00f90070 


 

00f90070 83ec08 sub esp,8 ; expand stack

00f90073 52 push edx

00f90074 8b54240c mov edx,dword ptr [esp+0Ch] ; get original retaddr

00f90078 89542408 mov dword ptr [esp+8],edx ; save as argv[1]

00f9007c c744240c5000f900 mov dword ptr [esp+0Ch],0F90050h ; inline hook renaming part as argv[2]

00f90084 c7442404c04a9200 mov dword ptr [esp+4],offset AcroRd32+0x14ac0 (00924ac0) ; hook handler as return address

00f9008c 5a pop edx

00f9008d c3 ret ; return to hook andler


 

: OpenEventW_Remaining

00f90050 8bff mov edi,edi

00f90052 55 push ebp

00f90053 8bec mov ebp,esp

00f90055 e9ab128f76 jmp KERNELBASE!OpenEventW+0x5 (77881305)


 


 

Our suggestion:


 

On our side, we will try to delay the function call to minimize the chance of this situation. On AcroRd32’s side, we suggest using a global flag to indicate AcroRd32's main/win main has been initialized. Before the initialization, the inline hook code should give up and not to call hook handler


 

For example

 

KERNELBASE!OpenEventW:

77881300 e96bed7089 jmp _precheck:


 

_precheck

mov eax, DWORD ptr [AcroRd32_SomeFlag]

test eax, eax

jz _skip


 

_original:

00f90070 83ec08 sub esp,8 ; expand stack

00f90073 52 push edx

00f90074 8b54240c mov edx,dword ptr [esp+0Ch] ; get original retaddr

00f90078 89542408 mov dword ptr [esp+8],edx ; save as argv[1]

00f9007c c744240c5000f900 mov dword ptr [esp+0Ch],0F90050h ; inline hook inline hook renaming part as argv[2]

00f90084 c7442404c04a9200 mov dword ptr [esp+4],offset AcroRd32+0x14ac0 (00924ac0) ; hook handler as return address

00f9008c 5a pop edx

00f9008d c3 ret ; return to hook andler


 

skip:

mov edx, offset AcroRd32+0x14ac0 (00924ac0) ; inline hook renaming part

jmp edx


 

: OpenEventW_Remaining

00f90050 8bff mov edi,edi

00f90052 55 push ebp

00f90053 8bec mov ebp,esp

00f90055 e9ab128f76 jmp KERNELBASE!OpenEventW+0x5 (77881305)


 


 

557
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
no replies

Have something to add?

Join the conversation