Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

Olly crashes whenever it sees a specific code at 0x14E2031

Found a bug in OllyDbg? Post a report here.
Locked
BoR0

Olly crashes whenever it sees a specific code at 0x14E2031

Post by BoR0 »

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
Attachments
ollycrash.zip
(210.66 KiB) Downloaded 437 times
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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: Select all

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: Select all

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
User avatar
dELTA
Posts: 4209
Joined: Mon Oct 30, 2000 7:00 am
Location: Ring -1

Post by dELTA »

Hehe, you rock blabberer. :yay:
"Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."
fr33ke
Posts: 109
Joined: Sat Jul 08, 2006 8:00 am

Post by fr33ke »

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: Select all

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: Select all

        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.
<[TN]FBMachine> i got kicked out of barnes and noble once for moving all the bibles into the fiction section
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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
Attachments
fltdbyterunning.zip
(135.39 KiB) Downloaded 400 times
BoR0

Post by BoR0 »

Haha, that's a nice fix blabb :devil:
Locked