I probaly use an old version (v.1.09d) and I'm sorry for not trying this bug on a new version but I won't risk messing up my settings for nothing atm

Anyways, the bug I found is as follows:

DBE3.....finit
CC........int 3

Upon breaking (I use Olly as JIT) I find myself on this line:

00401051 ^E3 CC JECXZ SHORT 0040101F

Hitting F7 for Single Step actually really jumps to 0040101F and that's a big NoNo

Hope someone can reproduce this.

Best Regards..
JC

you risk none of nothing by trying out the new version
just unzip to a new folder and set it up and run it if you prefer you can even copy paste the existing ollydbg.ini to the new folder and olly will inherit all the settings which you have
anyway i dont wish to comment on that part it is your prerogative to use
maybe even a older version of ollydbg

but as you say if you use olly as jit and it broke because of int3
then it should stop on the int3 command and not on any other
jecxz

and if you single step then it if you have a handler setup fot int3
it should get into handler
Log data, item 0
Address=00401003
Message=INT3 command at jmach.00401003

if no handler then
it should say
Log data, item 0
Message=Debugged program was unable to process exception

this is the default with behaviour (that means you have options --> debugging option -->exception --->ignore pass to program --> int3 check box checked

if you dont have the above int3 checked then it will simply step into next command wont care for that int3 exception

and jecxz is normally used in finding the version of windows
if you are using w9x as os jecxz will jump and if you are suing nt box it should not jump
if it was executing this code

00409068 MOV CX, CS
0040906A XOR CL, CL
0040906C JECXZ SHORT MISSION_.0040907A

so what you are saying is kinda unclear at the moment

Sorry for explaining myself unclearly.

The opcodes for finit are DB E3 and for int 3 the opcode is CC. This gives as disassembly the following:



Now the opcode for JECXZ SHORT 0040101F is E3 CC.

As you can see when Olly breaks it stops somehow in the middle of my finit and the int 3.

When I scroll up then it magically becomes finit and int 3 again and an F7 behaves as expected, if I don't it jumps to 0040101F and well crashes because at 0040101F there's something completely different going on.

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

Update: <u>I upgraded and Olly is well, now it works as it is supposed to. Should have done that in first place. </u>

well if some thing is jumping to some other opcodes middle
then you can always check off the
auto start analysis of main module in
options --> debugging options --> analysis1
olly will not auto analyze unless and untill you press ctrl+a

or if you prefer to keep it on you can right click --> analysis-->remove analysis from module
or remove analysis from selection

or better if seemed to look like it has stopped in middle of something
then double click the eip register it will point to the right instruction
that is about to execute

but one thing isnt still clear for me
i cant understand how it can jump to some arbitary location
from arbitrary looking visuals
some thing doesnt still gel with the explanation
i still assume it jumps to the handler and you are confusing yourself that
it is jumping to some arbitrary location

i must be having this 109d some where in some dust ridden cellar
if the code you talk about is small enough reply ill post my mail address
and i would give it a try to reproduce what you are talking

Hi Anon

Here you can Download Ollydbg 1.09d :
http://www.zdnet.com.au/downloads/0,39024478,39067711s,00.htm
("http://www.zdnet.com.au/downloads/0,39024478,39067711s,00.htm
")

Just use any project you got and insert a :

finit
int 3

and then run the thing after making sure that Olly 1.09d is your JIT.

I tried it on two computers, on both boxes the new Ollydbg (1.10) stops at an int 3 and on the old Ollydbg 1.09d it stops at an jecxz.

It's not a big deal, as it's fixed in the new version and that's the one I'll be using from now.

hehe i said i had it in my cellers anyway
if thats the only code then sure it will not jump to some arbitrary
place it is only erreneous reporting of Pseudeoopcode size
if you f7 it should pass to the next valid command not jump to
arbitrary location

any way it was bug that was reported
and corrected already

OllyDbg improperly decoded size of pseudooperand CX/ECX in commands like JCXZ/JECXZ, REP MOVSB or LOOPW/LOOPD. Bug reported by Karel.

look here for bug reports of previous versions

http://home.t-online.de/home/ollydbg/whatsnew.htm
("http://home.t-online.de/home/ollydbg/whatsnew.htm
")

and thats official site btw

I downloaded Ollydbg 1.10 and it improperly decoded size of pseudooperand CX/ECX in a REP MOVSB instruction.
This is really weird as Ollydbg version 1.09d has this bug fixed.