Log in

View Full Version : Olly crashes whenever it sees a specific code at 0x14E2031

BoR0
May 29th, 2007, 04:11
Olly crashes whenever it sees a specific code at 0x14E2031
----------------------------------------------------------
[==============]
Target: OllyDbg
Version: 1.10
Author: BoR0
[==============]

Starting story:

One morning I was debugging a tiny app. which made Ollydbg crash.
I was interested in how it crashed it so I started doing some research.

After some research I discovered that whenever Ollydbg sees these "special" bytes
at address 0x14E2031 it simply crashes.

The special bytes are:

olly_crash db
0DBh, 02Dh, 037h, 020h, 04Eh, 001h, 0FFh, 0FFh, 0FFh, 0FFh,
0FFh, 0FFh, 0FFh, 0FFh, 03Dh, 040h, 042h, 06Fh, 052h, 030h.


For more information regarding crash you can debug BORO.exe (source code included).

The program is a demonstration that allocates 16384 bytes at the memory 0x14E0000 and
then it writes the special bytes to 0x14E2031. It then jumps to a place where Ollydbg
will "see" the special bytes and then will instantly crash.


Bug discovered and article written by
Sitnikovski Boro - BoR0

29/05/2007
blabberer
May 29th, 2007, 05:00
yep i have seen this too it seems to be located on a bug or feature or something in shell32.dll

you can also make it crash by stopping very very early at LdrLoadThunk()

loading pdbs and then trying to find names in all modules

if you ollydbg as jit then the jit ollydbg will spawn multiple ollydbgs

continous crash and the AeDebug entry Will spawn several other ollydbgs
and finally will end up crashing the comp with no resources

to get out quickly before your comp crashes if you set ollydbg as jit to debug this

right click in taskbar -> properties -> group similar taskbar buttons -> close group
blabberer
May 29th, 2007, 05:50
ah shit your exe has got tnothing to do with what i mentioned in the previous post

most probably i have given the protection authours another avenue to look ways to crash ollydbg

your problem is you are trying to do fld tbyte -1

and ollydbg crashes trying to disassemble that instruction

and the bug iirc was traced back to borlands compiler floating point function
fistp

check fasm board for details about this little exe of yours

or below

Code:


004010EB      DB2D FC104000 FLD TBYTE PTR [4010FC]

004010F1      00            DB 00

004010F2      00            DB 00

004010F3      00            DB 00

004010F4      00            DB 00

004010F5      00            DB 00

004010F6      00            DB 00

004010F7      00            DB 00

004010F8      00            DB 00

004010F9      00            DB 00

004010FA      00            DB 00

004010FB      00            DB 00

004010FC      FE            ???                                      ;  Unknown command

004010FD      FFFF          ???                                      ;  Unknown command

004010FF      FFFF          ???                                      ;  Unknown command

00401101      FFFF          ???                                      ;  Unknown command

00401103      FF3D          ???                                      ;  Unknown command

00401105      40            INC EAX

00401106      0000          ADD [EAX],AL

00401108      0000          ADD [EAX],AL

0040110A      0000          ADD [EAX],AL

0040110C      0000          ADD [EAX],AL

0040110E      0000          ADD [EAX],AL

00401110      0000          ADD [EAX],AL



DS:[004010FC]=9.2233720368547758070e+18



just add 0.5 to the bove value and it will crash


you simply dont need to have any special place to be allocated you can simply code it in masm without all those moves

by using fld tbyte ptr ds:[VALUE]

here is your codes real dissassembly fetched via ntsd

Code:


0:000> u 14e2023 l12

014e2023 b837130000       mov     eax,0x1337

014e2028 0530526f42       add     eax,0x426f5230

014e202d 33c0             xor     eax,eax

014e202f ebf2             jmp     014e2023

014e2031 db2d37204e01     fld     tbyte ptr [014e2037]

014e2037 ffff             ???

014e2039 ffff             ???

014e203b ffff             ???

014e203d ffff             ???

014e203f 3d40426f52       cmp     eax,0x526f4240

014e2044 3000             xor     [eax],al

014e2046 0000             add     [eax],al

014e2048 0000             add     [eax],al
dELTA
May 29th, 2007, 07:06
Hehe, you rock blabberer.
fr33ke
May 29th, 2007, 08:14
This trick is used in TheMida sometimes. Link to fasm thread: http://board.flatassembler.net/topic.php?t=5820

You can patch your Olly to not die but show for instance 99999...:
Code:
004AA2F0  fld tbyte ptr [edx]

004AA2F2  fistp qword ptr [eax] ; Generates the C0000090 exception


Replace this with a jump to a cave and put code like this there:

Code:
        push    seh_handler                 ;Set up SEH frame

        xor     ecx, ecx

        push    dword [fs:ecx]

        mov     [fs:ecx], esp



        fld     tbyte [edx]

        fistp   qword [eax]

        wait                                ;Wait for possible exceptions



        pop     dword [fs:ecx]

        pop     ecx

        retn



backup:

        mov     dword [eax], 89E7FFFFh      ;decimal 99999999...

        mov     dword [eax+4], 8AC72304h

        pop     dword [fs:ecx]

        pop     ecx

        fnclex

        ffree   st(0)

        fincstp

        retn



seh_handler:

        mov     eax, [esp+0Ch]

        mov     dword ptr [eax+0B8h], offset backup

        xor     eax, eax

        retn


A better patch might be a full fix in the float2nicelyformattedumber routine but this is good enough for me.
blabberer
May 29th, 2007, 10:21
well all i wanted to say was which i actually forgot or missed is you dont have to run or single step the exe

its a complete static problem

it crashes while trying to disassemble and DISPLAY that code with exception c0000090 unknown exception the key word being display

you can simply have that as a string in hex some where
and if some one right clicks and chooses disassembly in dump window

ollydbg will crash without any problems

no need to run debug step

btw B0R0 one can run your exe in ollydbg without crashing too just make the disassembly window small enough to fit just one instruction
and you can your infinite loop infinitely without crashing

as you code doesnt get to show the crashing instruction ever

see the swf
BoR0
May 29th, 2007, 10:58
Haha, that's a nice fix blabb