I cant figure out what is wrong with this... if anyone can help me find out whats wrong it says that mov al, is access violation? and i dont know how to fix it ? basically im trying to go over the entire course of the depacker code and check for bpx at all locations.. by using the StartOfDepackerCode offset minus the value im currently at it just iterates though but its not working anyone know how i can make it work?



mov ecx, DEPACKER_CODE_SIZE ; offset StartOfDepackerCode - offset EndOfDepackerCode
@@bpx_loop: ; Start of loop
mov esi, offset StartOfDepackerCode ; esi = StartOfDepackerCode
sub esi, check_bpx_point ; esi = StartOfDepackerCode - current_offset_we_are_checking
add esi, OEP_EIP ; esi = esi + address of OEP
mov al, [esi] ; <--- causing access violation ??
mov ah, 022h ; loads ah with 22h
add ah, ah ; add it to itself, it results to 0x44
add ah, 088h ; add 88h result to CCh CCh is used for checking for breakpoint
cmp ah, al ; Compare to CCh
je BPX_FOUND ; Jump if equal (we are breakpointed)
xor eax, eax ; no breakpoint set eax to 0
jmp NO_BPX_FOUND ; Jump over, we didn't find any breakpoint
BPX_FOUND: ; Breakpoint found
mov eax, 1 ; EAX = 1
call ExitProcess ; Exit Program
jmp BPX_FOUND ; Loop infinitly just incase
NO_BPX_FOUND: ; No BPX was found continue...
add check_bpx_point, 01h ; current_offset_we_are_checking += 01h
dec ecx ; ecx = ecx - 1
jnz @@bpx_loop ; Loop until ecx is 0
Posted on 2004-02-04 18:27:50 by DevSpartacus
And before anybody gets the bright idea to erase this post - this is code for protection his *own* code, scanning for evil people setting breakpoints.
Posted on 2004-02-04 18:38:31 by f0dder
im thinking it might be the registers need to be larger in size.. i tried changing them to things like edx, ebx, ecx.. ect.. but now it causes the app to sometimes crash when ur going to click buttons and things.. not sure it must be the stack is messed up or somthing? anyone know how to fix?
Posted on 2004-02-04 21:51:06 by DevSpartacus
... and your sure the memory pointed to by esi is accessable for each time thru the loop?Have you checked what lies at this address when the violation ocurs?
Posted on 2004-02-04 22:39:56 by ENF
No.. I was able to bypass the erm.. bug with the esi thingy.. using larger registers.. then al and ah.. and i converted it to ecx and stuff as I explaiend now im just having problems with the values themself i dunno its all messed up now sometimes when i run an app encrypted with my pe cryptor.. which is what this is all is.. well.. if i click a butotn to do like.. select a file it crashes >.< i think it has to dow ith somthing wrong.. with the values after the loop or somthing now ? i wish other ppl would post :/ lol... been waiting all day :(
Posted on 2004-02-04 23:07:22 by DevSpartacus
Could this be a register presevation problem. Functions called by windows must restore ebx, esi and edi if they have been changed, if your peice of code is ever called from a window proc or any other function that returns to windows make sure to resote esi.
Posted on 2004-02-04 23:38:51 by ENF
how do i restore them :)
Posted on 2004-02-04 23:44:27 by DevSpartacus
push at the start of the function pop and the end
Posted on 2004-02-04 23:52:40 by ENF
I think i tired this.. but.. it didnt work ? :(
Posted on 2004-02-04 23:55:10 by DevSpartacus
I get this feeling that esi points to the section containing the code and does not have the readable flag set. Therefore when you attempt to read it there's a lovely error.

Regarding anti bpx try using GetCurrentContext and clear the bpx (values in the debug registers), best I think you generate an exception and handle it with seh calling the GetCurrentContext. Perhaps you can try wrap some portion of the code in seh and add an int 3 and modify some register in the exception. If you never land into the seh, then you can do the bad_guy_exit thingy.

Hmm there are some packers with nice anti debug tricks and perhaps you can have a look at them.
Posted on 2004-02-05 07:19:04 by roticv
funny... posting anti debug topics is allowed, but not reversing topics... although this is basically the same subject, you ve got to master each to be good in the other.

besides, some people are just curious and hungry for knowledge, and its not a crime...

pfff...
Posted on 2004-02-05 07:29:18 by HeLLoWorld

I get this feeling that esi points to the section containing the code and does not have the readable flag set. Therefore when you attempt to read it there's a lovely error.

*giggle*
You think that the processor would be able to execute the code, then? ;)


Regarding anti bpx try using GetCurrentContext and clear the bpx (values in the debug registers),

That handles DRx hardware BPs but not 0xCC BPs.


funny... posting anti debug topics is allowed, but not reversing topics... although this is basically the same subject, you ve got to master each to be good in the other.

It's a delicate subject... you don't want this board to get shut down because somebody think the DMCA or whatever is violated, do you?
Posted on 2004-02-05 07:35:08 by f0dder
mov esi, offset StartOfDepackerCode	; esi = StartOfDepackerCode

sub esi, check_bpx_point ; esi = StartOfDepackerCode - current_offset_we_are_checking
add esi, OEP_EIP ; esi = esi + address of OEP
What is OEP_EIP? If it is an address then that in the error. Adding two addresses together is a good thing only in rare cases.

Why obfuscated the code this way?

Try this: Push "repne scasb" and jump to the stack. This way the creation of the code on the stack can be spread throughout the depack code and used by the depack code as an integral part of the algorithm, and you could "jmp esp" (which is cool imho). Shouldn't cost too many bytes either - less than the above code. ESP should be set creatively as well.

Personally, I would create a depack algo that must be RE'd and recoded by a competent programmer -- something that can be jumped over is no good. The more layers of abstraction the better. The ExitProcess is a red flag to anyone.

This doesn't stop the use of hardware breakpoints.
Posted on 2004-02-05 09:41:03 by bitRAKE
OEP_EIP basically this I have a function at the OEP that grabs the EIP value.. I belive I saw it on here I belive roticv posted it looks like this:

call @F
@@:
pop eax ; eax = eip
sub eax, 5
mov OEP_EIP,eax

I have this at the OEP.. it just helps me correct the checking of offsets so that im not checking the exe cryptor but rather the file that is encrypted... its basically used as a location I do math with in order to determain the offsets of the rest of the code in the other exe.

I traced it using ollydebug and found it to be loaded with the correct offset value it was loaded with the offset of the entrypoint just as I intended but.. it had some weird access violation >.< error. once it got to the mov al,
part of the code.

Didn't know reverse engineering topics weren't allowed >.< but thats not really the question here, what im making, im making an exe cryptor, didn't think it would be a problem.

Any how im not to sure how to do what ur talking about bitrake with the, Push "repne scasb" jump stack thingy.. Not, to clear on all the asm things yet, so maybe make it a bit more clear.. just cuz im making the exe cryptor to make myself learn more asm.

So I can use it in other things like inline asm in c++ :) would help improve some performance with my main passion game programming, not to metion better debugging skills. So if you can help explain a bit more; on how to fix id be greatful.

I have already ruled out the thought that maybe it would be a bad idea, because maybe a data type or some thing like a jump or call would have 0xCC value in it but I thought even if it does.. I can rework the code to just check certain sections of code I know don't have a 0xCC value, so id like to be able to figure out how to make it work, if anyone can help.

I did some tracing using my debugger to help maybe someone can find out whats wrong I traced to the section of the code where my code is dieing and wrote down some stuff:


0040DE69 B9 F3180000 MOV ECX,18F3 ; mov ecx, DEPACKER_CODE_SIZE

0040DE6E BE 68244000 MOV ESI,test.00402468 ; mov esi, offset DepackerCode
----------------------
00402468=test.00402468


0040DE73 2B35 87254000 SUB ESI,DWORD PTR DS:[402587] ; sub esi, check_bpx_point
----------------------
DS:[0042587]=7941C130


0040DE79 . 0335 A8124000 ADD ESI,DWORD PTR DS:[4012A8] ; add esi, OEP_EIP
----------------------
; test.<ModuleEntryPoint>
----------------------
DS:[004012A8]=0040D0F0


0040DE7F . 8A06 MOV AL,BYTE PTR DS:[ESI] ; mov al, [esi]
=======================
Access violation when reading -> [873F3428]
-----------------------
DS:[873F3428]=???
AL=00
Posted on 2004-02-05 15:16:00 by DevSpartacus
DevSpartacus, was is the initial value of check_bpx_point?

Assuming that OEP_EIP is the actual address of the start of the code to test; your code will only work if check_bpx_point equals: offset StartOfDepackerCode - DEPACKER_CODE_SIZE + 1.

Do the math and you will see. I cannot compile an example here at work, but will try later when I have an assembler near.
Posted on 2004-02-05 16:05:15 by bitRAKE
check_bpx_point is initially set to 0:

check_bpx_point dd 0

thats alright i can wait im very happy u have made the offer you will try to assemble later its driving me nuts :confused:
Posted on 2004-02-05 16:07:48 by DevSpartacus
DevSpartacus, look at the result that you are after:

1. In the begining you want the address to test equal to OEP_EIP.

2. At the end you want the test address equal to OEP_EIP + DEPACKER_CODE_SIZE - 1

Therefore, how do you think you are getting the initial address?
offset StartOfDepackerCode + OEP_EIP != OEP_EIP ; because check_bpx_point is zero

Adding two addresses together has no meaning. A metaphor would be: You live in a house and on the same street lives your best friend and your grandmother. You can go to your friend's house or your grandmother's house, but what does it mean to say your going to (your friend's house plus your grandmother's house) --- you are somewhere way down the street but we don't know where.
Posted on 2004-02-05 16:41:24 by bitRAKE
how about this?
call delta

delta: pop ebx
sub ebx, delta

mov ecx, DEPACKER_CODE_SIZE ; offset StartOfDepackerCode - offset EndOfDepackerCode
@@bpx_loop: ; Start of loop
mov esi, offset StartOfDepackerCode ; esi = StartOfDepackerCode
sub esi, check_bpx_point ; esi = StartOfDepackerCode - current_offset_we_are_checking
add esi, ebx ; esi = esi + delta
mov al, [esi] ; <--- causing access violation ??
mov ah, 022h ; loads ah with 22h
add ah, ah ; add it to itself, it results to 0x44
add ah, 088h ; add 88h result to CCh CCh is used for checking for breakpoint
cmp ah, al ; Compare to CCh
je BPX_FOUND ; Jump if equal (we are breakpointed)
xor eax, eax ; no breakpoint set eax to 0
jmp NO_BPX_FOUND ; Jump over, we didn't find any breakpoint
BPX_FOUND: ; Breakpoint found
mov eax, 1 ; EAX = 1
call ExitProcess ; Exit Program
jmp BPX_FOUND ; Loop infinitly just incase
NO_BPX_FOUND: ; No BPX was found continue...
add check_bpx_point, 01h ; current_offset_we_are_checking += 01h
dec ecx ; ecx = ecx - 1
jnz @@bpx_loop
Posted on 2004-02-05 16:55:49 by ENF
Originally posted by DevSpartacus
0040DE73 2B35 87254000 SUB ESI,DWORD PTR DS:[402587] ; sub esi, check_bpx_point
----------------------
DS:[0042587]=7941C130
If check_bpx_point starts at zero, how did it become 7941C130h?
Posted on 2004-02-05 16:58:06 by bitRAKE
If check_bpx_point starts at zero, how did it become 7941C130h?


I have no idea...

how about this?


not work

however... it does loop a few times 0.0 unlike before.. not sure what its doing though 0.o im assuming it grabs the offset at delta location or somthings... it crashes somewhere... i think it crashed cuz it found 0xCC I just ran a trace...


and it crashes when it found that ;p but i think it may work
yea it does
...

final code:


call delta
delta: pop ebx
sub ebx, delta

mov check_bpx_point, 0
mov ecx, 100 ; offset check4bpx_start - offset check4bpx_end
@@bpx_loop: ; Start of loop
mov esi, offset check4bpx_start
sub esi, check_bpx_point ; esi = check4bpx_start - current_offset_we_are_checking
add esi, ebx ; esi = esi + address of OEP
.IF esi== 0040D992h ;<--- i traced until esi was equal to this.. so yea..
jmp end_loop ;<--- exits loop
.endif
mov al, [esi] ; al = [esi]
mov ah, 022h ; loads ah with 22h (half CCh)
add ah, ah ; add it to itself, it results to 0x44, and check
add ah, 088h ; add 88h result to CCh
cmp ah, al ; Compare ah to al
je BPX_FOUND ; Jump if equal (we are breakpointed)
xor eax, eax ; no breakpoint set eax to 0
jmp NO_BPX_FOUND ; Jump over, we didn't find any breakpoint
BPX_FOUND: ; Breakpoint found
mov eax, 1 ; EAX = 1
call ExitProcess ; Exit Program
db 0F0h,0Fh,0C7h,0C8h ; lock cmpxchg8b (e)ax this will crash SoftIce and all system
jmp BPX_FOUND ; Loop infinitly just incase
NO_BPX_FOUND: ; No BPX was found continue...
add check_bpx_point, 1 ; current_offset_we_are_checking += 1
dec ecx ; ecx = ecx - 1
jnz @@bpx_loop ; Loop until ecx is 0
end_loop:


thanks everyone for help dont have to end here though if anyone sees anything wrong or somthing 0.0

or any other ideas :)

only haaving a problem with like fixing or restoring the old values now but that should be easy to fix i think 0.0

the app runs now just like when u try to do things like click the button that brings up a common file select dialog it crashes.. when u click that.. but before it crashed on the loop itself so some progress. lol.. ok i fixed that
now all i gotta do is come up with some strange algorithm that will not detect CC values in my exe :) that are already there maybe count them?
Posted on 2004-02-05 17:01:25 by DevSpartacus