[ros-kernel] winhlp32 runs on reactos (the point to fix it)

[Waldo Alvarez Cañizares]

From: ros-kernel-bounces at reactos.com on behalf of Thomas Weidenmueller
Sent: Mon 4/26/2004 5:11 PM
To: ReactOS Kernel List
Subject: Re: [ros-kernel] winhlp32 runs on reactos

Mike Nordell wrote:

> As such, even if your patch stops it from crashing, because it hides other
>
>bugs I vote to not commit it.
>
> 
>
ok, that's what i wanted to know. i haven't tested how it really should
behave. Thanks for doing so.

Regards
Thomas
 
But you can commit the real fix
 
This is what's going on, Enjoy
 
Ok lets dissasemble winhlp32
 
IDA pro takes some time
 
lets see who calls strstr
 
ohoh the callers graph is so big that actually the computer starts to do lots of swapping

there are about 10 but they look like a million to me
 
this is not tha way
 
lets tweak strstr in msvcrt to print which string is comming in as NULL
 
hmm the first one
 
lets tweak it again to print the second if it is not NULL
 
FTUI comes out
 
hmm we are getting something here
 
lets ask cute IDApro who references that string
 
whoo a big graph again
 
wait a second... only one! we are closer!
 
anja

Code in winhlp32.exe (win2k)
.text:0100CAFA ; int __stdcall sub_100CAFA(LPCSTR lpString2)
.text:0100CAFA sub_100CAFA     proc near               ; CODE XREF: sub_100C1E9+10p
.text:0100CAFA                                         ; sub_100C444+A5p ...
.text:0100CAFA 
.text:0100CAFA sz              = byte ptr -104h
.text:0100CAFA lpString2       = dword ptr  8
.text:0100CAFA 
.text:0100CAFA                 push    ebp
.text:0100CAFB                 mov     ebp, esp
.text:0100CAFD                 sub     esp, 104h
.text:0100CB03                 push    [ebp+lpString2] ; lpString2
.text:0100CB06                 lea     eax, [ebp+sz]
.text:0100CB0C                 push    eax             ; lpString1
.text:0100CB0D                 call    ds:lstrcpyA
.text:0100CB13                 lea     eax, [ebp+sz]
.text:0100CB19                 push    offset aFtui    ; "FTUI"
.text:0100CB1E                 push    eax             ; lpsz
.text:0100CB1F                 call    ds:CharUpperA
.text:0100CB25                 push    eax
.text:0100CB26                 call    ds:strstr
.text:0100CB2C                 neg     eax
.text:0100CB2E                 pop     ecx
.text:0100CB2F                 sbb     eax, eax
.text:0100CB31                 pop     ecx
.text:0100CB32                 neg     eax
.text:0100CB34                 leave
.text:0100CB35                 retn    4
.text:0100CB35 sub_100CAFA     endp

would it be coming as NULL to sub_100CAFA in that case could 
take considerable time to find
 
would it be CharUpperA or lstrcpyA
 
well lets see the code of the closer one
 
Code in user32.dll (ReactOS text.c)
//LPSTR STDCALL CharUpperA(LPSTR lpsz)
/*
 * @implemented
 */
LPSTR WINAPI CharUpperA(LPSTR x)
{
    if (!HIWORD(x)) return (LPSTR)toupper((char)(int)x);
/*
    __TRY
    {
        LPSTR s = x;
        while (*s)
        {
            *s=toupper(*s);
            s++;
        }
    }
    __EXCEPT(page_fault)
    {
        SetLastError( ERROR_INVALID_PARAMETER );
        return NULL;
    }
    __ENDTRY
    return x;
 */
  return (LPSTR)NULL;  <---- returns a NULL if receives a string wich hapens in winhlp32
}
 
Voila, no tracing at all and just took minutes
I feel satisfied
 
Is a matter of fixing this little function to make it run or at least to be near that
point or is there something pending about SEH?
 
Please guys try to use open source software with ROS at least in the begining.
That will make things easier and we won't be forced to dissasemble software
that is not supposed to be. Right now i guess I'm bending the law, fortunately I don't
live in the US and I have some freedoms cause those laws can't be applied to me
 but let's make clear that I don't enjoy doing it, I just do it for ROS and I had no other
chance to find the bug. Also please do not partially disable some function again,
disable it entirely as most as you can, we could have saved us some time in here.
Fortunately this one came fast, others might take considerable time, keep it in mind.
 
btw I'm getting this one when winhlp32 closes (I'm not using the latest ROS but just to let know others
just in case somebody else faces it)
 
= MM_PPOOL_REDZONE_VALUE failed at mm/ppool.c:465
Bug detected (code 0 param 0 0 0 0)
  The bug code is undefined. Please use an existing code instead.
Frames: <ntoskrnl.exe: 969a> <ntoskrnl.exe: 96ba> <ntoskrnl.exe: 497a6> <ntoskrn
l.exe: 489df> <win32k.sys: 33d12> <win32k.sys: 4170c> <win32k.sys: 41dd7> <win32
k.sys: dadd> <ntoskrnl.exe: 60b1a> <ntoskrnl.exe: 5c622> <ntoskrnl.exe: 5c8da> <
ntoskrnl.exe: 33cc> <77F81C89> <77F1B99E> <78016C80> <78016C6F> <1034910> <77F1C
658> <DEADBEEF>
 
Best Regards
Waldo Alvarez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 12460 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040427/10e08285/attachment.bin