Re: revelation, snitch, openPass...

From: Valter Minute (vminuteat_private)
Date: Fri Jun 13 2003 - 00:44:40 PDT

  • Next message: averasat_private: "Revelation, snitch, openPass - Part 2"

    Alex Lambert wrote:
    >>I was wondering if someone know how these programs work. They 'reveal'
    >>passwords shown as **** in texboxes.
    >>
    >>Does anyone have any sourcecode? Explanation on how then work?
     >
    > Briefly, any window can touch any other window. Using the API, windows can
    > talk to each other (including changing others' controls, like the password
    > box).
    >
    
    Hi Alex,
    what you state here is true for all controls except the password text boxes.
    You can read control's text using WM_GETTEXT and change it using 
    WM_SETTEXT windows messages, but this doesn't work on edit fields 
    flagged with the ES_PASSWORD style (at least on windows NT/2K and XP, I 
    can't check 9X-based windows versions right now).
    I never tried to change the control's style at runtime, but I guess that 
    it's not possibile with those controls.
    So can't read the password ì directly, but, to answer Alisson's 
    question, it's not so difficult to do this kind of things (and standard 
    password boxes are not very secure).
    
    > There is a paper titled "Exploiting design flaws in the Win32 API for
    > privilege escalation" which discusses some of these problems available at
    > http://www.astalavista.com/library/basics/guides/Next-GenerationWin32exploit
    > s.htm.
    > 
    
    This is a different kind of problem.
    You can inject code inside the memory that an edit control uses to store 
    its text and execute it by sending a WM_TIMER message with a TimerProc 
    parameter set to point to the injected code.
    In this way the injected code could use the WM_GETTEXT message to read 
    the password box contents and send it to another process.
    The same kind of result could be archieved trough a system-wide hook.
    Hooks are a sort of "message-filters" that an application could install 
    to process keyboard or windows messages and, if the hook is system-wide 
    (the function should be inluded in a DLL), this allows you to load code 
    inside other processes (without the memory-address problems of the 
    approach outlined in the link that you provided).
    
    I hope that this information could satisfy Alisson's curiosity, even in 
    my poor english.
    
    Ciao,
    Valter
    



    This archive was generated by hypermail 2b30 : Fri Jun 13 2003 - 10:12:59 PDT