flat assembler
Message board for the users of flat assembler.

Index > Heap > Ollydbg bug

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Here is a little piece of code you may like to try. It looks quite innocent but it makes Olly crash.

Just assemble it as shown, then open the resulting *.exe under Ollydbg and watch while Olly crashes.

Anyhow, here it is just FYI:

Code:

include 'win32ax.inc'

start:  invoke  MessageBox,0,msg,head,0
        invoke  ExitProcess,0

func1:  mov     dword[dword ebx-1],-1
        cmp     eax,320
        ret
        db      0dbh

func2:  sub     eax,func1+2
        ret

head:   db      "Ollydbg will crash",0
msg:    db      "Hello. I'm working properly",13,10
        db      "But Ollydbg doesn't like me",0

.end    start

    


BTW: I use Ollydbg v1.10d, if you use a different version then perhaps this won't happen for you.
Post 10 Sep 2006, 14:01
View user's profile Send private message Visit poster's website Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
Nice, I'll play around with it later Smile
Post 10 Sep 2006, 15:45
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
hahahaha, you always find the most wierd bugs. How do you do that? Do you rely on some program verification theories? I know the existence of program correctness demostration in functional programming but I don't know if there is something like that for procedural programming.

Don't forget to report to the author Razz

Regards
Post 10 Sep 2006, 16:25
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
hahaha thats weird, could you find one that destroys all decompilers like that Very Happy Laughing
Post 10 Sep 2006, 17:42
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
locodelassembly wrote:
Don't forget to report to the author Razz

I believe dev'ing of OllyDbg is stopped...

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 10 Sep 2006, 18:04
View user's profile Send private message MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
locodelassembly wrote:
How do you do that?
Always test the boundary conditions, then the rest will fill in nicely.

I found this bug a few months ago but I never got around to posting it. I slightly obfuscated it just for fun (it is more fun to think about something than be given the answer directly, right?). But when you can work out why Olly crashes then you will see what is happening.
Post 11 Sep 2006, 00:33
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
okasvi wrote:
locodelassembly wrote:
Don't forget to report to the author Razz

I believe dev'ing of OllyDbg is stopped...


Appearantly he's working on v2 but progress is slow

_________________
Image - carpe noctem
Post 11 Sep 2006, 12:23
View user's profile Send private message Visit poster's website Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
Vasilev Vjacheslav
huh, now authors of super file protectors such execryptors (hello!) will use this nasty bug
Post 11 Sep 2006, 18:07
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
Vasilev Vjacheslav wrote:
huh, now authors of super file protectors such execryptors (hello!) will use this nasty bug


easy to 'fix' tho...

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 11 Sep 2006, 19:14
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
include 'win32ax.inc'

start:  fld     tbyte[crasherValue]

        invoke  MessageBox,0,msg,head,0
        invoke  ExitProcess,0 

head:   db      "Ollydbg will crash",0
msg:    db      "Hello. I'm working properly",13,10 
        db      "But Ollydbg doesn't like me",0 

crasherValue:
dq -1
dw $403D

.end    start    


A code that shows more clear what really happens Wink But I don't know which float value is it though Sad

[edit] I got it, is "dt 9.2233720368547758075e18" but I can't imagine why that value crashes olly[/edit]
[edit2]And actually there is more exponents that causes olly to crash with that mantissa[/edit2]
Post 11 Sep 2006, 19:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
locodelassembly wrote:
start: fld tbyte[crasherValue]
The "crasherValue" is a boundary condition. My theory is this: In some instances the mantissa causes a rounding to occur when it is stored as BCD (FBSTP) which then causes an overflow and stores a bogus BCD value in memory. At which point Ollydbg crashes when it tries to display/convert the bogus BCD value.

I have not taken the time to fully analyse the inner workings of Ollydbg so if someone can see the actual reason then don't forget post it here.

BTW: you don't actually need to execute the instruction, it is sufficient to have Ollydbg try to display the FLD instruction only. Thus, in my example, the FLD never gets executed but still causes Ollydbg to crash.

Another interesting/disturbing/annoying problem is if you have Ollydbg set for automatic attachment. The system keeps opening Ollydbg windows until you run out of memory. Fortunately Win2K and WinXP are stable enough to keep running without problem, but it is a pain to have to close all the windows manually.

My minimal code was this:
Code:
fld tbyte[$+6]
dt 9223372036854775807.5    
Post 12 Sep 2006, 00:58
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

BTW: you don't actually need to execute the instruction, it is sufficient to have Ollydbg try to display the FLD instruction only. Thus, in my example, the FLD never gets executed but still causes Ollydbg to crash.

yeah I know, it's just to make clear that the value doesn't generate any exception (remember that originally I didn't know the magic value).

Quote:
I have not taken the time to fully analyse the inner workings of Ollydbg so if someone can see the actual reason then don't forget post it here.

Seems that we need a debugger for the debugger Wink
Post 12 Sep 2006, 02:49
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
The bogus code:
Code:
* Referenced by a CALL at Addresses:
|:004AB918   , :004ABBEE   
|
:004AA2E0 8B442404                mov eax, dword ptr [esp+04]
:004AA2E4 8B542408                mov edx, dword ptr [esp+08]
:004AA2E8 66817A083E40            cmp word ptr [edx+08], 403E
:004AA2EE 7406                    je 004AA2F6
:004AA2F0 DB2A                    fld tbyte ptr [edx]
:004AA2F2 DF38                    fistp qword ptr [eax] ; Generates the C0000090 exception
:004AA2F4 9B                      wait
:004AA2F5 C3                      ret

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:004AA2EE(C)
|
:004AA2F6 8B0A                    mov ecx, dword ptr [edx]
:004AA2F8 8908                    mov dword ptr [eax], ecx
:004AA2FA 8B4A04                  mov ecx, dword ptr [edx+04]
:004AA2FD 894804                  mov dword ptr [eax+04], ecx
:004AA300 C3                      ret    
Post 12 Sep 2006, 02:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
locodelassembly wrote:
fistp qword ptr [eax] ; Generates the C0000090
This generates an #IA execption, and for some reason Ollydbg runs with the #IA exception ENABLED but does not properly trap the exceptions! Sloppy programming. FISTP will round up to 2^63 and causes #IA.
[edit]Changed overflow to #IA. Thanks locodelassembly for pointing that out[/edit]


Last edited by revolution on 12 Sep 2006, 07:45; edited 1 time in total
Post 12 Sep 2006, 04:26
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
format PE GUI 4.0

        finit
        fstcw    [fcw]
        and      [fcw], not $1
;        or       [fcw], $0400   ; Sets rounding control to round down (uncomment to stop the crashes)
        fldcw    [fcw]
        fld     tbyte[crasherValue]
        fistp   qword[output]
        wait
        ret

crasherValue dt 9223372036854775807.5
output dq ?
fcw dw ?    


"hacking" OllyDbg to use round down rounding control could be a reliable solution? I don't know very much about FPU programming (and actually I don't understand practically nothing of maths too Sad)
Post 12 Sep 2006, 04:36
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

This generates an overflow execption

Actually an Invalid Operation (IM) exception. I tried to debug with both WinDbg and W32Dasm v8.93 an both of them continously reports the exception without stopping. Only with W32Dasm v8.93 I was able to stop at the buggy instruction pressing "Step into" button while running in that maniatic loop. Maybe OllyDbg has SEH but it doesn't know how to handle an IM exception.

WinDbg's Console wrote:

.
[an insane amount of times "(2ec.4ac): Unknown exception - code c0000090 (first chance)"]
.
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.4ac): Unknown exception - code c0000090 (first chance)
(2ec.1098): Break instruction exception - code 80000003 (first chance)


[edit] Olly also crashes with dt 0.92233720368547758075 but causing a Precision Exception [/edit]
Post 12 Sep 2006, 04:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
locodelassembly wrote:
Actually an Invalid Operation (IM) exception.
You are right. I just tested and sure enough, #IA exception.
locodelassembly wrote:
Olly also crashes with dt 0.92233720368547758075 but causing a Precision Exception
This is not a boundary value:
mantissa: 0EC1E4A7DB69561A4h, Exp: 03FFEh.
But when converted to decimal it perhaps becomes that same as 9223372036854775807.5 (multiply by 1e19) just before converting to ASCII?
Post 12 Sep 2006, 07:39
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Sorry I said that at 2:00 AM. Olly still generates the same error code ($C0000090) so probably olly multiplies the value first (unfortunatelly I don't know how to show FPU values under W32Dasm, and with WinDgb I can't stop in the exception point so I can see the value of ST(0) at that moment Sad

I have no more debuggers and no time to make my own debugger to especifically check this Sad
Post 12 Sep 2006, 12:40
View user's profile Send private message Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
Vasilev Vjacheslav
fixed my ollydbg by locodelassembly method, thanx
Post 12 Sep 2006, 12:42
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I patched it some minutes ago using FISTTP (Floating Point Integer Trucate and Store). Now it shows that ST(0) is 9.2233720368547758070E+18 (which it's a little wrong). With "dt 0.92233720368547758075" show that ST(0) is 0.9223372036854775807 (again the 5 is missing). Note that with values like 2.5 olly shows 2.5000000000000000000 so maybe this solution fits perfectly but as I said before, I have not much experience with FPU programming and I'm very silly in maths.

[edit] I have checked that FISTTP is a very new instruction http://www.xbitlabs.com/articles/cpu/print/athlon64-venice.html so this patch is not so good. So a better choice could be patching the function to temporarily change the rounding control and then get it back to original value.[/edit]

[edit2] Ah, note that with values like "dt 2.77777777777777777777777777777777777777" shows 2.7777777777777777770 while the unpatched version shows 2.7777777777777777780 . Not a so good patch then Sad Maybe a code that handles the special situation could be better (or a rewritting of that function). [/edit2]
Post 12 Sep 2006, 13:10
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.