Jump to content
Tuts 4 You
_or_75

[UnPackMe] Safengine Shielden 2.2.6.0

Rate this topic

Recommended Posts

White

Is any HWID locked target ?


Share this post


Link to post
Share on other sites
LCF-AT

Hi,


 


hmm delicious UnpackMe. :)


Nice protected this time and thanks for posting _or_75. 


So I see this time you use also 2 more different VM parts.



<VM_DIRECT_COUNT> 00001078 | hex
<VM_STOLEN_COUNT> 0000039A | hex
<API_SEC_COUNT> 00000707 | hex

Ok so I only fixed all API counts now and the other 2 I did keep original = still access SE code to read stolen and hidden commands of codesection.The direct part I also keep original so I see that only the call commands of codesection was redirected to SE which later jump back to original codesection routine.


 


Ok so just test my unpacked file and tell whether it works for you.So I did unpack it on XP SP3 and it also works under Win7 32 Bit for me.


 


PS: Problem could maybe occur if in SE code happen some CPUID or RDTSC checks [VMProtect style] which I did not checked now.So if my unpacked file will not run for you then this should be the reason but if they will not checked inside then it will run for you.Just post your feedback later to know whether I also need to fix the stolen and direct VM too.


 


greetz


 


EDIT: Ok so it seems to be again a upload & download problem and nobody said anything.Why? :)


Here I did upload my file on extern host.


Project1_se_Unpacked.rar (2.38MB)


Project1_se_Unpacked.rar

Project1_se_Unpacked - Upload 2 Try.rar

Edited by LCF-AT (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites
L4Nce

hi


I have unpacked this file.But now it is 2 am in China.I can't find more friends to test it.i just test it in xp sp3 and win7 32bit.


I don't find any public script for se in China.I don't know why.Maybe it is a balance between unpacker and pack-writer.


I fix all iats,reloc calls,stolen codes and res and now i just have one problem.


The problem is CreateThread.Se deals with this api in speical way.i need to run my script again and again to find all CreateThread's position and then updata my script. :wallbash: 


Could you give me some advice?


Sorry for my poor english.


greetz


Attached Files

unpack.rar


 


Just as LCF-AT says forum's download has some problem.


I updata my attached file in other place.



unpack File


Edited by L4Nce (see edit history)

Share this post


Link to post
Share on other sites
Teddy Rogers

Just as LCF-AT says forum's download has some problem.

 

The server has been detecting these files as being malicious that is why there is a problem. You should be able to download these files as normal now...

 

Ted.

Share this post


Link to post
Share on other sites
L4Nce

The server has been detecting these files as being malicious that is why there is a problem. You should be able to download these files as normal now...

 

Ted.

Thank you :-)

Share this post


Link to post
Share on other sites
SmilingWolf

Both LCF-AT's and L4Nce's unpacked files works on my machine (Win7 32bit).


Congrats!


Share this post


Link to post
Share on other sites
_or_75

Hi,

 

hmm delicious UnpackMe. :)

Nice protected this time and thanks for posting _or_75. 

So I see this time you use also 2 more different VM parts.

<VM_DIRECT_COUNT> 00001078 | hex

<VM_STOLEN_COUNT> 0000039A | hex

<API_SEC_COUNT> 00000707 | hex

Ok so I only fixed all API counts now and the other 2 I did keep original = still access SE code to read stolen and hidden commands of codesection.The direct part I also keep original so I see that only the call commands of codesection was redirected to SE which later jump back to original codesection routine.

 

Ok so just test my unpacked file and tell whether it works for you.So I did unpack it on XP SP3 and it also works under Win7 32 Bit for me.

 

PS: Problem could maybe occur if in SE code happen some CPUID or RDTSC checks [VMProtect style] which I did not checked now.So if my unpacked file will not run for you then this should be the reason but if they will not checked inside then it will run for you.Just post your feedback later to know whether I also need to fix the stolen and direct VM too.

 

greetz

 

EDIT: Ok so it seems to be again a upload & download problem and nobody said anything.Why? :)

Here I did upload my file on extern host.

Project1_se_Unpacked.rar (2.38MB)

 

Win 7 32 bit, works :)

Win XP SP3 32 bit, works :)

Share this post


Link to post
Share on other sites
GIV

So you got a script that does all unpack.


:man:





<VM_DIRECT_COUNT> 00001078 | hex
<VM_STOLEN_COUNT> 0000039A | hex
<API_SEC_COUNT> 00000707 | hex


Share this post


Link to post
Share on other sites
LCF-AT

Hi,


 


so I wrote a little basic unpacker script (only test version) which prevents Pre-DLL Emulation,fix Resources RD,find OEP.So for the IAT and other VM stuff I still use MultiASM so there I wrote a code which does log all different important founds of IAT / APIs / VM etc into different log sections and for fixing the APIs I use a second script I wrote.


 


All in all I could add all in one script later.Before a while I did start to write a MultiASM tracer code but I did not work on it for a longer while so if I work on it again then it could trace any routines in realtime to solve them all straight without using a script anymore = fixing all in one second. :) Normaly not necessary for me alone but if I should write a public script this year (maybe) then I will do this so.Will see. :) So till then you guys can post more unpackmes.


 


@ L4Nce


 


CreateThread & CreateProcessA you can handle manually.No big deal so far.So why do you have to run your script again & again?So I don't know how your script works but my script does run just one time.Also you should try to hook the possible exceptions via (KiUser) to catch problems and to log and prevent a process exit.Also you can patch CreateThread directly + in memory if you did not prevent the dll emulations or just patch the CreateThread protection threads itself.Just play a little.


 


PS: In your unpacked file you did fix the call to CreateProcess jmp with CreateThread = wrong.Just a info.The rest is nice unpacked and you could also reduce your dumped size to under 400 KB now instead of 16 MB.


 


greetz


Share this post


Link to post
Share on other sites
LCF-AT

Hi,


 


hmmm so now its bad at the moment to check your new file so a good friend did send me a hardcore WL UnpackMe where I work on it now. :) Just wait till I am finished (1 or 2 days or 6 months) :)


 


greetz


Share this post


Link to post
Share on other sites
L4Nce

@LCF-AT

hi Lcf-at

I know this file.

You Can't miss unpcakme about Safengine NetLicensor.

When I talk about unpacking Safengine Shielden whit my friends in Chinese crack forum 52pojie,Nooby come and give us this demo.(http://www.52pojie.cn/thread-235837-3-1.html)

Safengine Shielden is a free Protection.We can get it easily from http://www.safengine.com/,so there are some weak points in it.

In this Safengine NetLicensor demo,Nooby says it is very slow ,because when we step in Safengine' call,we will meet VM immediately.

This is just a powerful unpackme,but it is too slow to commercial software.

I think it is a delicious food for you.Don't mis it! :smilie3:

Share this post


Link to post
Share on other sites
LCF-AT

Hi guys,


 


@ White、、


 


Ok so today I also unpacked the NetLicensor protection which does differ from the other SE protections but after some tracings and checkings I found the right places and unpacked this too. :) All in all both protections are almost the same and none of them is harder or easier to unpack.


 


greetz


Safengine NetLicensor v2.2.6.0_UnPackMe_Unpacked_x2.rar

  • Like 3

Share this post


Link to post
Share on other sites
L4Nce

@LCF-AT


WOW!LCT-AT ,only sky is your limit!


In this SL File,Nooby did not use api hash table,so all api will get real address at one place.(Maybe CreateThread is an excetion)


I use next steps to find the key point.


1.SE'vm handler entry is push reg;ret then use conditional bp to pass some pop/push etc handler.


2.Running some times I can find api name's string.(in vEsp)


3.Set memory access break point and run again,I can find a comparing code about api'name string.


4.At the moment,I use step and find the key point.


In this file,key ponit is "010BF536    E8 4E000000     call Safengin.010BF589"


I only get api real address,but a big problem comes whitch is I can't get iat type (call [dword];jmp [dword] ;call xxxx xxxx:jmp [dword] and mov reg,[xxxx] call reg)


I also find the code to fix return address but it is in the vm code:



0118DEDD 66:D3C1 rol cx,cl
0118DEE0 66:F7D3 not bx
0118DEE3 0147 04 add dword ptr ds:[edi+0x4],eax ;edi is the vreg ponit.
0118DEE6 EB 33 jmp short Safengin.0118DF1B
0118DEE8 8F07 pop dword ptr ds:[edi]


I believe you have analysed all vm code but if you have some useful technique to find iat tpye could you tell me about it.


THX


Edited by L4Nce (see edit history)

Share this post


Link to post
Share on other sites
LCF-AT

@ L4Nce


 


First I have again to say that I am always trying to find easy and simple solutions if possible so thats my first step.The first address you found at 010BF536 is already the right address to get all raw API in edi to see (APIs and forwarded API names).


 


1.) 010BF536 = Get APIs


 


So as next you try to find where the APIs and EMUlated APIs get stored in real IAT of target



0108FE24 MOV DWORD PTR DS:[EDX],ECX

Ecx does copy the real API or EMU API into target IAT.So all in all what you here can do is to hook this 2 addresses = Get API and write API where you enter the real API into [edx] only and set the eip over the command.If you now stop at OEP then you have your IAT filled with real API addresses except the 2 forwarded APIs of ntdll Get & SetError...but these you can fix later before you finished.


 


2.) Now you need to solve all calls to SE code which are in this file just API commands of different types (call dword / jmp dword / call to jmp dword and mov R32,dword).Also this problem you can find out very simple without to trace into the VM.



010073AC CALL 011C60CF <-- 1. call to SE after OEP
010073B1 LODS BYTE PTR DS:[ESI]
010073B2 CALL EDI

So the first call of this file after OEP is at 010073AC.All what you have to do is again to hook the Get API address which is the same at VA 010BF536 = GetModuleHandleA in edi.As next the API get changed to the EMU API of GMHA and this EMU API address will also stored into SE section itself so just set now a memory BP write on SE section and run =



01194FEA MOV DWORD PTR DS:[EAX],ECX
ECX=00B5ACB6
DS:[011C5061]=00000000
DS:[011C5061]=00B5ACB6 <-- EMU now

Ecx = EMU API of GMHA which will copy to 011C5061.Now there are 2 possible ways what should comes next.


 


The API / EMU API will access and executet or not.If the API will not executet then its a mov R32,dword API type = you come out of the SE code without to access the API and the API / EMU API is to see in the registers.If the API will access then its a direct API access type.


 


Simple handling exsample:



010073AC CALL 011C60CF <-- 1. call to SE after OEP
010073B1 LODS BYTE PTR DS:[ESI]
010073B2 CALL EDI 010BF536 Get API in edi Mem BP write at SE code = stop at VA XY = differs Also this mov [r32],r32 does differ so you need to check both r32
commands to know where the API get stored and which R32 command hold
the API / EMU API xy 01194FEA MOV DWORD PTR DS:[EAX],ECX // Write API to SE location [EAX] = API SE location = note address
011C5061 00B5ACB6 Type: Set BP at API / EMU API in ECX = 00B5ACB6
Set Mem BP access on codesection
Now run
------------------------------------
Now we stop at code VA 010073B2 CALL EDI
------------------------------------
So that means the API was not access and we just come back
to codesection.Now check the register and we will see the
EMU GMHA address 00B5ACB6 in my case. If we come back to code without to access the API = mov R32,dword API Type!
All what we have to do now is to check the register to find the address of
00B5ACB6 and we find it in EDI = mov edi,dword [IAT XY];GetModuleHandleA Now check IAT which we fixed before and find GMHA API and you find it at VA
010010CC | 7C80B741 kernel32.GetModuleHandleA Now the API command = mov edi,dword [010010CC]; GHMA Fix API Type correctly
--------------------------------------
$ ==> 010073AC E8 1EED1B00 CALL 011C60CF <-- CALL to SE
$+5 010073B1 AC LODS BYTE PTR DS:[ESI]
$+6 010073B2 FFD7 CALL EDI <-- Back to code 010073B2 - 010073AC = 6 bytes So that means that out API Type command has to use 6 bytes = mov edi,dword [010010CC]; GHMA = 6 bytes lenght Normaly all mov R32,dword commands has 6 bytes except mov eax, can also
use only 5 bytes (A1 opcode) Summary:
-----------------------------------
call to SE - Come back to code with access the API = mov R32,dword Type
call to SE - Access API - come back to code = call dword / jump dword / call to jmp dword So to find that other types out you only need again to calc..... Address to SE VA - Back to code VA = 5 = call to jump dword [IAT]; API
Address to SE VA - Back to code VA = 6 = call dword [IAT] ; API
Address to SE VA - Back to code VA = not 5 or 6 = jump dword [IAT] ; API So that are the command types are used and you can find out on a simple way
and then just create them at SE call. Next important step is that you fill the SE API location again with a 00 dword =
011C5061 00B5ACB6
to
011C5061 00000000 to prevent that SE is not going a other way = API was already read.
Just read the infos only and just clean the API location at the end thats all.

So all in all its almost pretty simple to find and use the easiest way to handle this problems and for this you can also write a small script which just runs a few minutes to fix all SE calls to the right API commands and addresses of the IAT.


 


Info: Before you let enter a SE call you should set the registers except esp to 00 each time so that you can check the register for your xy API / EMU API if you have to handle a mov command type.Also set the esp address same before you enter a SE call to prevent a stack overflow etc.If you do then all is going fine wihtout any problem and at the end you just dump / fix normaly and you got your unpacked file.One info.....so there are also just a few jmp dword [] to fix so for this you need to give them a new location address so in my case I did used...0100CD60 (+6 bytes for each new)



0100CD60 - FF25 BC120001 JMP DWORD PTR DS:[10012BC] ; WINSPOOL.OpenPrinterW
0100CD66 - FF25 B4120001 JMP DWORD PTR DS:[10012B4] ; WINSPOOL.GetPrinterDriverW
0100CD6C - FF25 B8120001 JMP DWORD PTR DS:[10012B8] ; WINSPOOL.ClosePrinter
0100CD72 - FF25 B4120001 JMP DWORD PTR DS:[10012B4] ; WINSPOOL.GetPrinterDriverW
0100CD78 - FF25 B8120001 JMP DWORD PTR DS:[10012B8] ; WINSPOOL.ClosePrinter
0100CD7E - FF25 24130001 JMP DWORD PTR DS:[1001324] ; msvcrt._initterm
0100CD84 - FF25 24130001 JMP DWORD PTR DS:[1001324] ; msvcrt._initterm
0100CD8A - FF25 EC120001 JMP DWORD PTR DS:[10012EC] ; msvcrt._XcptFilter
0100CD90 - FF25 3C130001 JMP DWORD PTR DS:[100133C] ; msvcrt._controlfp

Thats all what I can say about this protection to handle it on a easy way. :) So I hope that you can follow my descriptions to unpack the target also by yourself.


 


greetz


Share this post


Link to post
Share on other sites
L4Nce

@LCF-AT


hi LCF-AT thanks for your detailed descriptions.i have finshed this traget.


I have try this way sometimes before i asked you,but it crashed.When i see you say "fill the SE API location again with a 00",I think i know the reason.


I find an address at 010BE397,(this position se translate real api to  shadow api) and patch it so all api is real address.


so i don't need to analyse where is the shadow address.I jmp the store code.so i don't need to analyse store address.


Here is my ugly script:



;/////////////////////////////////////////////////////////////////////
;/ugly script
;just for Safengine NetLicensor v2.2.6.0_UnPackMe.exe
;by L4Nce[C.L.G]
;/////////////////////////////////////////////////////////////////////
var Code_Base
var Code_Size
var Se_Data
var Se_Datasize
var Se_DataEnd
var OEP
var Key_Addr
var Fix_addr
var Real_Addr
var Entry_Call
var Mov_Code
var Patch_Address
var Temp
var OEsp
var Ret_Addr
var FF25_CODE
var Iat_Addr mov Iat_Addr,011f1000
mov FF25_CODE,0100B94B
mov Code_Base,01001000
mov Code_Size,12000
mov Se_Data,01013000
mov Se_Datasize,001DE000
mov Se_DataEnd,011F1000
mov OEP,0100739F
mov Key_Addr,010BF536
mov Buffer,011f1fd0
mov Patch_Address,010BE397 bp OEP
RUN
bc OEP
mov OESP,esp
mov Fix_addr,Code_Base
mov [Patch_Address],c021,2
FIND_LOOP:
mov esp,OESP
find Fix_addr,#E8??????00#
test $RESULT,$RESULT
je END
mov Fix_addr,$RESULT
mov Entry_Call,$RESULT
inc Fix_addr
gci $RESULT,DESTINATION
cmp $RESULT,Se_DataEnd
ja FIND_LOOP
cmp $RESULT,Se_Data
jb FIND_LOOP mov eip,Fix_addr
dec eip
mov eax,-1
mov ebx,-1
mov ecx,-1
mov edx,-1
mov edi,-1
mov esi,-1
mov ebp,-1
bp Key_Addr
run
mov Real_Addr,edi
bc Key_Addr
BPWM Se_Data,Se_Datasize
run GCI eip,SIZE
add eip,$RESULT BPMC
BPRM Code_Base,Code_Size
bp Real_Addr
run
BPMC
bc cmp eip,Real_Addr
je CALL_CASEA
add Entry_Call,5
cmp eip,Entry_Call
je MOV_EAX inc Entry_Call
cmp eip,Entry_Call
je MOV_REGS pause MOV_EAX:
sub Entry_Call,5
mov [Entry_Call],B8,1
mov [Entry_Call+1],Real_Addr,4
jmp FIND_LOOP MOV_REGS:
sub Entry_Call,6
cmp ebx,0
mov Mov_Code,BB
je FILL_CODE cmp ecx,0
mov Mov_Code,B9
je FILL_CODE cmp edx,0
mov Mov_Code,BA
je FILL_CODE cmp esi,0
mov Mov_Code,BE
je FILL_CODE cmp edi,0
mov Mov_Code,BF
je FILL_CODE cmp ebp,0
mov Mov_Code,BD
je FILL_CODE FILL_CODE:
mov [Entry_Call],Mov_Code,1
mov [Entry_Call+1],Real_Addr,4
mov [Entry_Call+5],90,1
jmp FIND_LOOP CALL_CASEA:
mov Ret_Addr,[esp],4
sub Ret_Addr,5
cmp Ret_Addr,Entry_Call
je CALL_JMP
dec Ret_Addr
cmp Ret_Addr,Entry_Call
jne JMP_IAT
sub Real_Addr,Entry_Call
sub Real_Addr,5
mov [Entry_Call+1],Real_Addr
mov [Entry_Call+5],90,1
jmp FIND_LOOP
CALL_JMP:
asm FF25_CODE,"jmp dword ptr [00401000]"
mov [Iat_Addr],Real_Addr,4
mov Real_Addr,FF25_CODE
mov [FF25_CODE+2],Iat_Addr
add FF25_CODE,6
add Iat_Addr,4
sub Real_Addr,Entry_Call
sub Real_Addr,5
mov [Entry_Call+1],Real_Addr
jmp FIND_LOOP
JMP_IAT:
sub Real_Addr,Entry_Call
sub Real_Addr,5
mov [Entry_Call+1],Real_Addr
mov [Entry_Call],e9,1
mov [Entry_Call+5],90,1
jmp FIND_LOOP END:
mov eip,OEP
sub eip,2
asm eip,"push 70"
msg "Please uif fix,dump and rebulid iat."
ret

this is unpacked file


unpack.rar


LCF-AT,you is an enthusiastic and powerful man!


Now I am your fan.


 


greetz


Edited by L4Nce (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites
LCF-AT

Hi L4Nce


 


ok I have test your script so far and found also a problem.So you remember that I told you that there are also some forwarded APIs where you can't set a BP on it so thats just API string names.



Exsample:
-----------------------------------------------------
ASCII "NTDLL.RtlGetLastWin32Error"
ASCII "NTDLL.RtlSetLastWin32Error"

Now you try to set a BP on that strings where it will never stop and you just come back to codesection via mem BP access and now your script does think its a mov R32 API type and does fix it also as mov R32 command but its a call dword [] command = all of them are fixed wrong also in your dump.



0100424E E8 ADB81A00 CALL 011AFB00
to
0100424E BD DB90807C MOV EBP,7C8090DB ; ASCII "NTDLL.RtlGetLastWin32Error"
01004253 90 NOP In your dump =
0100424E MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
010043E0 MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01004A17 MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01004E4F MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01004EE8 MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01006B2F MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01006D4B MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01006D94 MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01006DAF MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error
01006E94 MOV EBP,DWORD PTR DS:[11F13E4] ntdll.RtlGetLastWin32Error 01004BFA MOV EBP,DWORD PTR DS:[11F13EC] ntdll.RtlSetLastWin32Error
01006B12 MOV EBP,DWORD PTR DS:[11F13EC] ntdll.RtlSetLastWin32Error
01006D8E MOV EBP,DWORD PTR DS:[11F13EC] ntdll.RtlSetLastWin32Error So all should be call dword [] commands

Just check the API in register if you stop at mem BP write where it copy the API to SE code then you see the real direct API where you then can set the BP.Just only a info of course for you my fan. :) So as you can see its not so hard to handle this protection so far right.


 


PS: Nice work and keep going L4Nce. :)


 


greetz


Share this post


Link to post
Share on other sites
L4Nce

@LCF-AT


oh I forget this ponit,thanks!


I fix my script like below




bp Key_Addr
run
LOOP_AGAIN:
mov Real_Addr,edi
BPWM Se_Data,Se_Datasize
run
cmp eip,Key_Addr
je LOOP_AGAIN

Now I think I have solve this problem.

Attached Files has my new script and new unpacked fileunpack2.zip

greetz


  • Like 1

Share this post


Link to post
Share on other sites
converse
On 03.03.2014 at 9:49 PM, LCF-AT said:

@ L4Nce

First I have again to say that I am always trying to find easy and simple solutions if possible so thats my first step.The first address you found at 010BF536 is already the right address to get all raw API in edi to see (APIs and forwarded API names).

 

1.) 010BF536 = Get APIs

 

 

 

 

hi LCF-AT

how did you find this address? more if you can

Share this post


Link to post
Share on other sites
LCF-AT

Hi,

so you are asking to late. :) Its already two years ago.You find this address into the calls to SE which are commands to APIs / Emu API etc.You have to trace them.Also you can set BPs on export table datas of dlls like kernel.Now trace and check what the protector does and you will find this address where you get the API address in register.Just check this out again.Remember,find the SE location inside the call where the API / EMU API gets filled into.If you got it then set it back to 0 and now you can call the same call again.

greetz

Share this post


Link to post
Share on other sites
converse
12 hours ago, LCF-AT said:

Hi,

so you are asking to late. :) Its already two years ago.You find this address into the calls to SE which are commands to APIs / Emu API etc.You have to trace them.Also you can set BPs on export table datas of dlls like kernel.Now trace and check what the protector does and you will find this address where you get the API address in register.Just check this out again.Remember,find the SE location inside the call where the API / EMU API gets filled into.If you got it then set it back to 0 and now you can call the same call again.

greetz

possible details with addresses and when to set a breakpoint ???

I sent you a PM in a sample in which it is impossible to recover the import, look and tell me what is the reason? thank you in advance

Edited by converse (see edit history)

Share this post


Link to post
Share on other sites
LCF-AT

Hi,

the protector needs to read the datas from export table of a dll and does compare it with API strings to find the right API address of API xy the SE protector call wants to get.Its checking and getting the datas from the tables.All what you have to do is to find the locations / loops where it does happens inside of the SE call.

First comes a call to GetModuleHandleA API / EMU API address what gets the dll base of desired dll.Now check the dll base and set mem BP access on codesection on dll and you stop right there where it reads the export table datas AON NON etc.From here you can trace forward and check what it does.I made short steplist for that file..

010BF187   CALL 01062568  // Name check compare
010BF18C   CALL 010BF1C1  // check ends *A1
--------------------------------------------------
010ADDFF   TEST CL,CL  // Checks API name opcode 

010ADFC3   JE 010ADDFF  // jumps if same (edx & edi) API Name opcode

010ADF01   JE 010ADE3E  // jumps if name check ends (match or not match)
--------------------------------------------------
*A1 Here you come out 010BF18C
In eax you see 0 or 1 or -1
Now you enter 2. call

010BF1C5   TEST EAX,EAX  // Check

010BF1AF   JE 010BE638  // jumps if eax was 0 = same API NAME before

010BF48E   MOVZX EAX,WORD PTR DS:[EAX+EBX*2]

eax = AddressOfNameOrdianls Table start
ebx = Ordinal
esi = Dll Export Table VA (kernel in my case)

Does copy Ordinal to eax (0176 in my case)

010BF4AB   MOV ECX,DWORD PTR DS:[ESI+0x1C]

Copy AddressOfFunctions Table RVA to ecx (2654)

010BF4B6   LEA ECX,DWORD PTR DS:[ECX+EAX*4]

eax 00000176 Ordinal
ecx 00002654 AOF Table RVA 
*4
= 00002C2C

010BF4D9   MOV EAX,DWORD PTR DS:[EDX] // kernel base to eax

010BF508   MOV EDI,DWORD PTR DS:[EAX+ECX]

EAX 7C800000 kernel32.7C800000
ECX 00002C2C
=
7C802C2C  0000B741
=
0000B741 in edi // AOF X RVA

010BF534   ADD EDI,EAX // Add kernel base to edi

0000B741 + 7C800000 = 7C80B741 GetModuleHandleA

010BF536   CALL 010BF589 // Here the call you wanted to find

Now you got the API in register what SE wants
Trace inside the call too...

010BE397  ADD EAX,ESI  // eax = API VA (Nop this command to prevent EMUlation of the API)

Thats all so far how you can find the address where you see the API raw.Its just a question of tracing / checking where it reads the datas from the export tables.If you found then find the right checks where you can bypass the loops to prevent endless tracings.

greetz

Share this post


Link to post
Share on other sites
Teddy Rogers

You could have if you had followed the rules of the forum you attempted to create it in...

Ted.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×