I can't get it work !!!
It always halt with "error 11" message. What to do?
In SoftICE it does not happens with the same programs. Maybe I miss something in settings?

Now it's something new (after restart)
ERROR_CLASS_DOES_NOT_EXIST (00000583) ??? Why??? There are all clases there

Never in my life OLLYDBG tell me ERROR 11, and i have 185 tutorials and 150 challenges, do you use Panda Antivirus, the enemy of OLLYDBG?

Ricardo

No, there is TrendMicro installed on the machine... So what 's the problem?

greets

well as far as i know ther is no error level 11 string in olly
the nearest string is

Text strings referenced in OLLYDBG:.text, item 1860
Address=00447BF3
Disassembly=PUSH OLLYDBG.004B3E3A
Text string=ASCII "(Last error = %s)"

does the popup belong to olly or does it belong to application

what does it say actually

what are you doing to get it

all this info may help us help you

just by saying woahhhhhhhh i got err0r 11 doesnt make a cleare picture

and if you have panda antivirus many say it tinterferes with the debuggers process so ric asked if you have it installed

so instead of asking "i have trend micro whats the problem"
why dont you try disabling it for some time run olly and see if this probalem goes off if not tell that tooetc etc

blind questions does not get any replies or gets at the most blind replies

regards

Thank you for response, as following:
1) The problem is with application debugged, but not with Olly
2) The application running in debug mode, using Olly just halted after a couple of seconds, so it is impossible to debug.
3) When the appliction halted it can be ERROR_CLASS_DOES_NOT_EXIST (00000583) or
ERROR_SUCCESS (00000000) last error state
4) While this the stack is
Call stack of thread 000009EC
Address Stack Procedure / arguments Called from Frame
01CFFE48 77F5C454 Includes 7FFE0304 ntdll.ZwTerminateProcess+0A 01CFFF40
01CFFE4C 77E798EC Maybe ntdll.ZwTerminateProcess kernel32.77E798EA 01CFFF40
01CFFF44 77E7990F ? kernel32.77E79895 kernel32.77E7990A 01CFFF40
01CFFF58 004545FA ? kernel32.ExitProcess hb3.004545F4 01CFFF54
01CFFF5C 00000002 ExitCode = 2
01CFFF64 00454542 ? hb3.00454557 hb3.0045453D
01CFFF74 0043C453 hb3.00454535 hb3.0043C44E
5) I have trendmicro, but I do not think that it the problem
6) ntdll halt string is 77F5C448 >/$ B8 01010000 MOV EAX,101
77F5C44D |. BA 0003FE7F MOV EDX,7FFE0300
77F5C452 |. FFD2 CALL EDX
77F5C454 \. C2 0800 RETN 8
7) That's all folks . So I'm wonderring what is the problem here 'cos in SoftICE this does not happens, but I prefer to use Olly (love it)...
8) Thanks to all

does it create any exception if you want to know do this
alt+0 debugging options,exceptions ,add last exception

it will be grayed if ther was no exception else if it is enabled the top most is the recent exception
if you want you can allow olly to pass it to the applications handler rather than letting olly handle it

it saves you pressing shift+f9 umpteen times

are you attaching it
or are you loading it

does it stop on entry point have you read its pe header entry point
is it packed have you unpacked it

if sice can work on this app (if it is an app and not some driver)
then olly can work with it too and better than sice

I added 0-FFFFFFFF in skip error on debug option- nothing (still halting)
How to post to app handle?
I'm load it
the application in unpacked
So still problems, what to do>? Something I missed?

Greetings,

the problem is that one win32 API call returns ERROR_CLASS_DOES_NOT_EXIST (00000583) and the thread/program terminates upon (due to application error handling).
The error code could be related to window classes (registered atoms) but it can be anything other too.

At first you must identify the API call that caused the last error code.
To do so, set a conditional breakpoint at ntdll.RtlSetLastWin32Error.
Condition "[ESP+4] == 0x583" (first arg is win32 last error code).

Let the program run and watch it stop.
Collect all data - especially the call stack - and post it here.

View -> callstack
"show arguments"
copy whole table to clipboard.

With this information we might help you...

Regards,

A. Focht

Here the dump
Call stack of thread 000014C4
Address Stack Procedure / arguments Called from Frame
01CFFF64 00456115 ntdll.RtlSetLastWin32Error hb3.0045610F 01CFFFB4
01CFFF68 00000000 Error = ERROR_SUCCESS
01CFFF74 0045387E hb3.004560B3 hb3.00453879 01CFFFB4
01CFFF78 0043C3D6 hb3.00453879 hb3.0043C3D1 01CFFFB4

ERROR_CLASS_DOES_NOT_EXIST (00000583)

Condition "[ESP+4] == 0x583" (first arg is win32 last error code).

01CFFF64 00456115 ntdll.RtlSetLastWin32Error hb3.0045610F 01CFFFB4
01CFFF68 00000000 Error = ERROR_SUCCESS

sort of messup some where where ????

btw why dont you try following the calls using show calls or going to stack following it to dissembler and break pointing the return and see if olly breaks

That's what it return to me with condition [ESP+4] == 0x583

Hi again,

as "oh me anon" already mentioned - there is something messed up.

Ollydbg should never break on conditional if arg0 = 0 (Error = ERROR_SUCCESS)

Next try: do a conditional log breakpoint.

Condition: "[esp+4] == 0x583"
Explanation: "lasterror code"
Expression: "[esp+4]"
decode: assumed by expression
Pause program/log: on condition

Run the program.
If that doesnt work (breaks even if lasterror != 0x583), try condition "[esp+4] != 0".
It will break/log on every API error encountered.

Dont come back until lasterror code "00000583" is logged

Regards,

A. Focht

I think is a antidebugger code in the program.

The program can generate the errors.

1)I try disabling all breakpoints and all hardware BPX, enabling the plugin IsDebuggerPresent for hide of detection for this api
2)You can use WindowsHacker for hide the windows of olly to hide detection for the name of the Window of OLLYDBG.
3)Also you can rename the exe of ollydbg for hide of detection for name of the process
4)You can create a infinite loop in the EP of program and when is looping, atach the olly for hide detection of api Process32first, Process32Next (ACProtect method), this detect the process who load the process of the program, and if olly load the program is detected how the program who create the process.(if you atach a program looping in your EP olly is not detected how creator of the process)

If you try all of this options and continue the problem try
HE RaiseException if the program stop look if there are a conditional jump to skip this api and run the program.

Ricardo Narvaja

hey ricardo ,

just to be sure i want to know this coz i dont use sice

and you seem to be doing some good job writing so much tuts
if this is antidebug then how come sice can handle it with aplomb
and not show his error 11

any ideas if sice has some extra capability to by pass antidebug
;(

i have my doubts like this

1) he hasnt set any break points so itmust be running in full steam
2) he must have f9 ned it and it and pressed some check the message box is result of his doing not ollys
3)it has to stop in the entry point of packer atleast if it is packed
there is no way that it can execute all by itself
4) if it is executing by itself then the ntdll.dll debug break must be screwed up without screwing it up each and every exe must stop at some entry point wherther it is original or packers or some devils entyr point isnt it
5) without executing any code in application no antidebug worth its salt is going to help
6) there is no way i think to find if the app is running in the contextof debugger during loading process (am i right or wrong
any one reading this may comment on this point

can the system determine if an app is running in the context of debugger and take evasive action without running any of its code

7) ???? what else i dunno but i firmly believe if sice can handle it then olly must be able to handle it

all and any comments are welcome

OK, thanks to all.
There are two options:
1) new version of Olly solved the problem
2) IsDebuggerPresent plug in make it's work ...

Nice day to all

Yes is possible execute code, before reach the entry point, look the dll when are charging and put BP in ENTRY POINT of dlls and i see one program with this protection, it has a dll special, this was executed before reach the EP, and test the CRC32 and send a messageboxa with a ridicoulous error.

Put the mark OLLY stop in load of each dll and you don't look of ssystem dlls, look the dlls of the program (in the folder of the program), and put a bpx in the entry point and llok how execute code of the dll easily

Ricardo

by entry point you mean the entry point of exe not the packer

in that proggie you mention does the unpacker routine gets executed which then might have executed the dll

then it still falls under executing user code

coz the dll is mapped to space by zwMapFileView calls int 2e
and then it returns that is all i ve seen tracing the loading process
no where i have seen some code being executed

can you point me to the proggie or sample you talk about

if its off limits then gimme your mail so ill mail you

EP is the first line executed in a pcked program, and OEP is the original enty point when you unpack a file, you may found the OEP, but this is not the first line executed, the packer unpack befores the program.
In the program i see the dll is executed before the olly stop in the EP, and no line of the program are executed, and in the dll the program check for crc32, etc, and a messagebox say ERROR XXX and exit, and no line of the exe was executed.
The tut is in my ftp and mi mail is ricnar22@millic.com.ar and the program was part of a weekly contest of crackslatinos mail list.
When you change only a byte the dll check crc32 and messagebox say error and exit program, before the exe are excuted, the packer unpack, and before OLLYDBG execute one only line of code of the exe and exits before reach the OEP.

Ricardo

Sorry EXIT before reach the EP.

Ricardo

I think my english is very bad but is very simple, a dll is executed before the exe start, and block the program and no line of the exe was still executed.

Ricardo

so basically what you are trying to say is the unpacker routine executes the dll and exits if the crc is not ok
before reaching 401000 (i assume it will be 401000 as it is the address for most exe)
===============================================

-------olly stop here (404567 for example entry point for unpacker)
--------------------|
--------------------|
-------------unpacker routine
--------------------|
--------------execute dll ------->check crc ------------> not ok
------------------------------------------|-----------------------|
------------------------------------------ok------------ error msg box
------------------------------------------|------------------------|
-------------------------------jmp to entry point------------exit
------------------------------- (maybe 401000)

===============================================

any way ill mail you ill like to look at it

No no, you dont, understand me.

With your grafic explain better

--------------execute dll ------->check crc ------------> not ok
ok error msg box ----------------------------------------------|-----------------------
-------olly stop here (404567 for example entry point for unpacker)
--------------------|
--------------------|
-------------unpacker routine
--------------------|
------------------------------------------|-----------------------|
-|
-------------------------------jmp to entry point---------- exit
------------------------------- (maybe 401000)
===============================================

The program execute dll and olly NO EXECUTE and NO REACH THE EP (in your exmaple 404567)
If the check are good olly stop in 404567, unpack next and go to OEP.
If the check are bad OLLY NEVER EXECUTE 404567, the dll exit before.

Ricardo

Digo yo, no hay nadie que hable español que explique en ingles que el programa ejecuta una dll antes de llegar al EP, que olly nunca lo arranca si el crc esta mal, pues la dll te hace salir del programa ANTES DE QUE OLLY PUEDA LLEGAR AL EP?

CHEQUEO DE DLL

SI ES NO OK ----------> EXIT
SI ES OK ---------------> OLLY PARA EN EL EP

DAS RUN

UNPACKER

OEP

Esa es la secuencia espero que alguien lo entienda

Ricardo

hehe ricardo
google gave me this
Say I, is nobody speaks Spanish who explains in ingles that the program executes a DLL before arriving at the EP, that olly never takes it if crc this badly, because the DLL makes you leave the program BEFORE OLLY CAN ARRIVE At the EP? DLL CONTROL IF ----------> EXIT IS noncOk IF ---------------> OLLY FOR IN EP DAS RUN UNPACKER OEP That IS OK is the sequence I hope that somebody understands Ricardo to it

ok ok i got it any way ive sent you a mail

Would it be useful if you suspend all process’ threads before you debug? So the process could not detect any changes ?!?

This is, more than anything, the reason I'm so glad Olly now can debug DLLs.

Way cool find, btw. I knew PE loader had to load the DLLs to resolve things like where they would reside in memory and IAT, but it never occured to me it would execute any of the DLLs code. Could come in VERY usefull. Think of an INSTANT pop to debugger on a process creation that uses a DLL you want to watch, or better yet, instant pop on things using WinSock or what not. Very usefull indeed!

I wonder... If a packed program needed additional DLLs that the packer didn't need, wouldn't they have to be loaded in on a CORRECT IAT (before scrambling)?

Lots of possibilities...

hey ricardo it uses this way to do what you have said

it calls the dllentrypoint and does what you suggest to execute before going to entry point

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllpr oc/base/dynamic_link_library_entry_point_function.asp ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_library_entry_point_function.asp")



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllpr oc/base/dllmain.asp ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp")

very good jeje

Ricardo