Application hijacking?

Discussion in 'NZ Computing' started by ~misfit~, Sep 8, 2005.

  1. ~misfit~

    ~misfit~ Guest

    On firing up my PC this morning I get a scary message from Sygate:

    "Application Hijacking has been detected
    The application: D:\Program Files\D-Tools\daemon.exe try to launch another
    application: C:\Program Files\Google\Gmail
    Notifier\G001-1.0.25.0\gnotify.exe to go to remote host mail.google.com"

    Ok, Gmail notifier has permission to access the web, Daemon tools doesn't. I
    found this a little scary so I ran AdAware, Spybot S&D and then AVG 7, all
    with the latest definitions, all came up clear. I got this message three
    times and each time was a different IP (in place of where this warning says
    mail.google.com, this was the most recent warning), although they all
    resolved to Google.

    I want to be able to check my email so I gave Daemon Tools access to the
    web.

    Anyone have any idea what's going on? Both have been installed for quite a
    while, as has Sygate. I also connect through a router, Alcatel Speedtouch
    510, which I'm sure has a firewall built in as I've never had an "attack"
    show in Sygate on any of my machines. I also run XP's firewall (sp2)
    concurrently.

    Thanks.
    --
    ~misfit~
    ~misfit~, Sep 8, 2005
    #1
    1. Advertising

  2. In article <431f8dc7$>,
    says...
    > On firing up my PC this morning I get a scary message from Sygate:
    >
    > "Application Hijacking has been detected
    > The application: D:\Program Files\D-Tools\daemon.exe try to launch another
    > application: C:\Program Files\Google\Gmail
    > Notifier\G001-1.0.25.0\gnotify.exe to go to remote host mail.google.com"
    >
    > Ok, Gmail notifier has permission to access the web, Daemon tools doesn't. I
    > found this a little scary so I ran AdAware, Spybot S&D and then AVG 7, all
    > with the latest definitions, all came up clear. I got this message three
    > times and each time was a different IP (in place of where this warning says
    > mail.google.com, this was the most recent warning), although they all
    > resolved to Google.
    >
    > I want to be able to check my email so I gave Daemon Tools access to the
    > web.
    >
    > Anyone have any idea what's going on? Both have been installed for quite a
    > while, as has Sygate. I also connect through a router, Alcatel Speedtouch
    > 510, which I'm sure has a firewall built in as I've never had an "attack"
    > show in Sygate on any of my machines. I also run XP's firewall (sp2)
    > concurrently.
    >
    > Thanks.
    >


    Shaun, I've seen this very behaviour from Sygate. In my case it claimed
    that the HP printer driver was trying to launch all manners of software
    (e.g. internet apps). What's worse, from that point on Sygate no longer
    retains permissions granted even if you tell it to do so.

    Something somewhere in there has gone screwy, and I am not sure if it's
    part of Windows (corrupted handles database?) that is doing the wrong
    attribution or if it's Sygate.

    In any way, what solves it for me is to shut down, cut the power off at
    the UPS for 10 - 15 seconds and rebooting.

    It's happened about two or three times this year so far .... not really
    a big issue.

    -P.

    --
    =========================================
    firstname dot lastname at gmail fullstop com
    Peter Huebner, Sep 8, 2005
    #2
    1. Advertising

  3. ~misfit~

    Tim Guest

    Peter,

    > Something somewhere in there has gone screwy, and I am not sure if it's
    > part of Windows (corrupted handles database?) that is doing the wrong
    > attribution or if it's Sygate.


    FYI: - if this bores you, then oh well....

    "Windows" Handles - there are two major categories
    Kernel (system) - and
    User

    and many different types
    - GDI - graphics related including pens, fonts, brushes, regions etc,
    - Process,
    - Thread,
    - Window,
    - File,
    - Socket, etc. etc. etc.

    They are held in in-memory tables that are built anew every time you boot.
    A handle is an identifier for that particular instance of an object type
    which are usable only by the Win32 API's that relate to that handle type.
    User-mode handle tables are initialised anew when a user logs on.

    There is an in-memory 'table' for each 'class' or type of handle (all GDI
    handles are in one table I think) and with User handles (those unique to the
    user logon session and of a type that the system does not need to know
    about, or need to know "all" about) held in the User session memory - for
    user handles, there is a separate set of such tables for each logged on user
    session. Kernel handles are held in kernel (system) memory and as such are
    internally (to windows) "shared" and accessable system wide - EG a file
    handle is in kernel memory and records the "who, what, when, where" of the
    file, and process / thread that has opened it - the handle details are
    visible widely within kernel so that kernel can do obvious things like check
    to see if a file is already open when trying to open it exclusively in
    another process. Access to kernel handles is restricted as appropriate by
    User / Session etc. to the process that asked for the creation of the
    handle - handles can in some situations be passed between processes /
    sessions to facilitate communications. EG windows handles can be posted to
    in another process.

    If such a table were to become corrupt then either the system, user-session,
    or process would promptly crash. IMHO, the most likely causes for Handle
    table corruptions will be
    User Handles: possibly really cruddy software or memory errors,
    Kernel Handles: memory is unstable (run memtest86 and Prime95 to verify
    basic memory system stability), or a really flakey device driver which is
    possible for a firewall application that installs its own device drivers.
    Windows itself is unlikely to be the cause of such a corruption as the code
    is extremely mature, would result in voluminous reports of BSOD's / many app
    crashes and would get addressed really quickly as a stability issue.

    You would be extremely likely to get a BSOD with an uncommon STOP code for
    kernel handle table corruptions.

    ..... now, did you mean something else when refering to a handle??

    I would suspect the software concerned in this case. There are utilities
    available that enable you to inspect / monitor the various types of handles
    in use. I think it is sysinternals.com that has some good utilities. There
    are also Task Manager alternatives that will show considerable information
    on Processes, Handles / types etc.

    - Tim
    Tim, Sep 8, 2005
    #3
  4. ~misfit~

    ~misfit~ Guest

    Tim wrote:
    > Peter,
    >
    >> Something somewhere in there has gone screwy, and I am not sure if
    >> it's part of Windows (corrupted handles database?) that is doing the
    >> wrong attribution or if it's Sygate.

    >
    > FYI: - if this bores you, then oh well....
    >
    > "Windows" Handles - there are two major categories
    > Kernel (system) - and
    > User
    >
    > and many different types
    > - GDI - graphics related including pens, fonts, brushes, regions etc,
    > - Process,
    > - Thread,
    > - Window,
    > - File,
    > - Socket, etc. etc. etc.
    >
    > They are held in in-memory tables that are built anew every time you
    > boot. A handle is an identifier for that particular instance of an
    > object type which are usable only by the Win32 API's that relate to
    > that handle type. User-mode handle tables are initialised anew when a
    > user logs on.
    > There is an in-memory 'table' for each 'class' or type of handle (all
    > GDI handles are in one table I think) and with User handles (those
    > unique to the user logon session and of a type that the system does
    > not need to know about, or need to know "all" about) held in the User
    > session memory - for user handles, there is a separate set of such
    > tables for each logged on user session. Kernel handles are held in
    > kernel (system) memory and as such are internally (to windows)
    > "shared" and accessable system wide - EG a file handle is in kernel
    > memory and records the "who, what, when, where" of the file, and
    > process / thread that has opened it - the handle details are visible
    > widely within kernel so that kernel can do obvious things like check
    > to see if a file is already open when trying to open it exclusively
    > in another process. Access to kernel handles is restricted as
    > appropriate by User / Session etc. to the process that asked for the
    > creation of the handle - handles can in some situations be passed
    > between processes / sessions to facilitate communications. EG windows
    > handles can be posted to in another process.
    > If such a table were to become corrupt then either the system,
    > user-session, or process would promptly crash. IMHO, the most likely
    > causes for Handle table corruptions will be
    > User Handles: possibly really cruddy software or memory errors,
    > Kernel Handles: memory is unstable (run memtest86 and Prime95 to
    > verify basic memory system stability), or a really flakey device
    > driver which is possible for a firewall application that installs its
    > own device drivers. Windows itself is unlikely to be the cause of
    > such a corruption as the code is extremely mature, would result in
    > voluminous reports of BSOD's / many app crashes and would get
    > addressed really quickly as a stability issue.
    > You would be extremely likely to get a BSOD with an uncommon STOP
    > code for kernel handle table corruptions.
    >
    > .... now, did you mean something else when refering to a handle??
    >
    > I would suspect the software concerned in this case. There are
    > utilities available that enable you to inspect / monitor the various
    > types of handles in use. I think it is sysinternals.com that has some
    > good utilities. There are also Task Manager alternatives that will
    > show considerable information on Processes, Handles / types etc.


    Thanks for that Tim, it mostly went over my head as I'm more of a hardware
    man myself but I've filed it away in case I need it in future.

    Cheers,
    --
    ~misfit~
    ~misfit~, Sep 8, 2005
    #4
  5. ~misfit~

    ~misfit~ Guest

    Peter Huebner wrote:
    > In article <431f8dc7$>,
    > says...
    >> On firing up my PC this morning I get a scary message from Sygate:
    >>
    >> "Application Hijacking has been detected
    >> The application: D:\Program Files\D-Tools\daemon.exe try to launch
    >> another application: C:\Program Files\Google\Gmail
    >> Notifier\G001-1.0.25.0\gnotify.exe to go to remote host
    >> mail.google.com"
    >>
    >> Ok, Gmail notifier has permission to access the web, Daemon tools
    >> doesn't. I found this a little scary so I ran AdAware, Spybot S&D
    >> and then AVG 7, all with the latest definitions, all came up clear.
    >> I got this message three times and each time was a different IP (in
    >> place of where this warning says mail.google.com, this was the most
    >> recent warning), although they all resolved to Google.
    >>
    >> I want to be able to check my email so I gave Daemon Tools access to
    >> the web.
    >>
    >> Anyone have any idea what's going on? Both have been installed for
    >> quite a while, as has Sygate. I also connect through a router,
    >> Alcatel Speedtouch 510, which I'm sure has a firewall built in as
    >> I've never had an "attack" show in Sygate on any of my machines. I
    >> also run XP's firewall (sp2) concurrently.
    >>
    >> Thanks.
    >>

    >
    > Shaun, I've seen this very behaviour from Sygate. In my case it
    > claimed that the HP printer driver was trying to launch all manners
    > of software (e.g. internet apps). What's worse, from that point on
    > Sygate no longer retains permissions granted even if you tell it to
    > do so.
    >
    > Something somewhere in there has gone screwy, and I am not sure if
    > it's part of Windows (corrupted handles database?) that is doing the
    > wrong attribution or if it's Sygate.
    >
    > In any way, what solves it for me is to shut down, cut the power off
    > at the UPS for 10 - 15 seconds and rebooting.
    >
    > It's happened about two or three times this year so far .... not
    > really a big issue.


    Ok, thanks for that Peter. I'll do as you say, remove permission for Daemon
    tools to access the internet, and see how I go. If that fails I may
    uninstall and reinstall Sygate.

    Cheers,
    --
    ~misfit~
    ~misfit~, Sep 8, 2005
    #5
  6. ~misfit~

    ~misfit~ Guest

    ~misfit~ wrote:
    > Peter Huebner wrote:
    >> In article <431f8dc7$>,
    >> says...
    >>> On firing up my PC this morning I get a scary message from Sygate:
    >>>
    >>> "Application Hijacking has been detected
    >>> The application: D:\Program Files\D-Tools\daemon.exe try to launch
    >>> another application: C:\Program Files\Google\Gmail
    >>> Notifier\G001-1.0.25.0\gnotify.exe to go to remote host
    >>> mail.google.com"
    >>>
    >>> Ok, Gmail notifier has permission to access the web, Daemon tools
    >>> doesn't. I found this a little scary so I ran AdAware, Spybot S&D
    >>> and then AVG 7, all with the latest definitions, all came up clear.
    >>> I got this message three times and each time was a different IP (in
    >>> place of where this warning says mail.google.com, this was the most
    >>> recent warning), although they all resolved to Google.
    >>>
    >>> I want to be able to check my email so I gave Daemon Tools access to
    >>> the web.
    >>>
    >>> Anyone have any idea what's going on? Both have been installed for
    >>> quite a while, as has Sygate. I also connect through a router,
    >>> Alcatel Speedtouch 510, which I'm sure has a firewall built in as
    >>> I've never had an "attack" show in Sygate on any of my machines. I
    >>> also run XP's firewall (sp2) concurrently.
    >>>
    >>> Thanks.
    >>>

    >>
    >> Shaun, I've seen this very behaviour from Sygate. In my case it
    >> claimed that the HP printer driver was trying to launch all manners
    >> of software (e.g. internet apps). What's worse, from that point on
    >> Sygate no longer retains permissions granted even if you tell it to
    >> do so.
    >>
    >> Something somewhere in there has gone screwy, and I am not sure if
    >> it's part of Windows (corrupted handles database?) that is doing the
    >> wrong attribution or if it's Sygate.
    >>
    >> In any way, what solves it for me is to shut down, cut the power off
    >> at the UPS for 10 - 15 seconds and rebooting.
    >>
    >> It's happened about two or three times this year so far .... not
    >> really a big issue.

    >
    > Ok, thanks for that Peter. I'll do as you say, remove permission for
    > Daemon tools to access the internet, and see how I go. If that fails
    > I may uninstall and reinstall Sygate.


    Worked a treat Peter, thanks. I opened Sygate and rescinded permission for
    Daemon to access the 'net and clicked OK. Instantly I got a warning pop-up
    and Gmail notifier wasn't connecting. I powered down the machine, unplugged
    the PSU and made a coffee. On re-booting everything's fine and dandy.

    Much obliged.
    --
    ~misfit~
    ~misfit~, Sep 8, 2005
    #6
  7. In article <dfo9hr$68c$>, says...
    >
    > .... now, did you mean something else when refering to a handle??
    >
    > I would suspect the software concerned in this case. There are utilities
    > available that enable you to inspect / monitor the various types of handles
    > in use. I think it is sysinternals.com that has some good utilities. There
    > are also Task Manager alternatives that will show considerable information
    > on Processes, Handles / types etc.


    That was eggs-acktly what I was referring to. I do have the sysinternals
    tool, b.t.w (several of them in fact).

    When something happens like ~misfit~ describes then one of my suspicions
    is that an application is starting a thread, but the ownership of the
    handle for that thread is (falsely) attributed to a different
    application, and this is where the firewall spits the dummy.

    Does that make sense in any way to you?

    Yeah, corrupted memory is my main suspect - all it takes is one bit in
    one pointer. That doesn't necessarily even mean that the ram chips are
    BAD, but I do have issues like that maybe half a dozen times a year
    where everything goes screwy, and is fixed by a power down ... not
    really bad for a machine that runs > 12 hours every day and sometimes a
    couple of weeks 24/7 without a reboot or even a logoff.
    But from time to time apps still seem to manage to overwrite
    'protected' memory.

    -P.


    --
    =========================================
    firstname dot lastname at gmail fullstop com
    Peter Huebner, Sep 8, 2005
    #7
  8. ~misfit~

    Tim Guest

    inline...

    "Peter Huebner" <> wrote in message
    news:...
    > In article <dfo9hr$68c$>, says...
    >>
    >> .... now, did you mean something else when refering to a handle??
    >>
    >> I would suspect the software concerned in this case. There are utilities
    >> available that enable you to inspect / monitor the various types of
    >> handles
    >> in use. I think it is sysinternals.com that has some good utilities.
    >> There
    >> are also Task Manager alternatives that will show considerable
    >> information
    >> on Processes, Handles / types etc.

    >
    > That was eggs-acktly what I was referring to. I do have the sysinternals
    > tool, b.t.w (several of them in fact).
    >
    > When something happens like ~misfit~ describes then one of my suspicions
    > is that an application is starting a thread, but the ownership of the
    > handle for that thread is (falsely) attributed to a different
    > application, and this is where the firewall spits the dummy.
    >
    > Does that make sense in any way to you?


    Sort of. File handles are supposed to be cloned and marked (DuplicateHandle
    API) before they are passed to another process (as an example) so that
    Windows knows in advance that the programmer is doing this on purpose.
    Handles are quite water tight because the only valid way of using a handle
    is to use one of the API's specifically coded to use a handle of that
    type... but some programmers do dicky things. EG one very common commercial
    app caused MS some sweat (reportedly) because there were tens of millions of
    copies installed and the app was large and the app was consistently coded
    wrong - it utilised a bug in the version of Windows it supported - that you
    could at some point still process a file using a handle that had been
    closed. They had coded the app to clos files as soon as they were open so
    that programmers did not forget to close them! MS had to (reportedly)
    retrofit this bug into later OS versions so as not to break the app, but
    also hard code the fix so that it only worked for that app! (A "famous" MS
    programmer has documented this nightmare).

    Most handles can't be passed around willy nilly - the system stops this, but
    handles are often simple numeric values EG 4, 8, 12, 16 with some base
    number (IE the handle value can be a memory address, an index, an offset
    from some base address or a magic number of any type - whatever is most
    convenient and appropriate for the API authors) so if some idiot does some
    maths on the handle EG adds 4 intentionally or not via a bug, (which you
    must never do as the handle should only ever be a parameter to an API
    designed to use it and knows what it is for) then goodness knows - you could
    ge a process name misreported due to some accidental slack programming. This
    actually sounds quite plausible in the case you site as one of the not so
    easy things to do in windows is to get object 'Name' from Handles. Try
    getting the name of another processes Image file (exe) in another process -
    not easy, so programmers often fundge reads into kernel memory to manually
    lookup tables that have been documented only by deduction, not MS... and
    change between OS version / Service Pack. Getting an index or offset in a
    complex table structure wrong is easy to do when what you are trying to
    navigate is undocumented...

    Thats a long winded way of say that it is possibly an application s/w error.

    If you are experiencing periodic weirdness then a memtest86 overnight won't
    hurt - if your system has memory issues, then often these can be fixed
    simply by changing a timing parameter... or getting ECC :) Prime95 torture
    test is reportedly good at bringing out funamental system stability issues.
    If either of these highlights issues then post back...

    If a user process gets a corrupted handle value inside user mode code then
    chances are the user application will spontaneously crash. EG a file read on
    a handle which is not open in this user process will give an IO error
    response from the API which if not checked for will result in sporadic
    application behaviour and likely an app crash.

    Many of my systems run 24 x 7. My old Dual Proc Asus P2B-DS (no ECC RAM)
    server ran up to over 7000 hours between reboots without issue (Orignally
    NT4, then W2K, then Wndows 2003 Server, Exchange, ISA, SQL Server, file
    sharing etc. lightly loaded but a lot of s/w). It never crashed unless I did
    something dicky with a device driver, so my opinion is that running 24 x 7
    for XP or W2K SP 4 or later or W2K3 is not an issue on lightly loaded system
    (at least - customers have plenty of busy systems that run just as long
    between boots and have no issues).

    That's my way of recommending memtest86 / prime95 and checking your device
    drivers - run sigverif. Your h/w may be flakey or you may have a duff device
    driver.

    - Tim


    > Yeah, corrupted memory is my main suspect - all it takes is one bit in
    > one pointer. That doesn't necessarily even mean that the ram chips are
    > BAD, but I do have issues like that maybe half a dozen times a year
    > where everything goes screwy, and is fixed by a power down ... not
    > really bad for a machine that runs > 12 hours every day and sometimes a
    > couple of weeks 24/7 without a reboot or even a logoff.
    > But from time to time apps still seem to manage to overwrite
    > 'protected' memory.
    >
    > -P.
    >
    >
    > --
    > =========================================
    > firstname dot lastname at gmail fullstop com
    Tim, Sep 8, 2005
    #8
  9. ~misfit~

    ~misfit~ Guest

    Tim wrote:

    <Snippety do-dah>

    > That's my way of recommending memtest86 / prime95 and checking your
    > device drivers - run sigverif. Your h/w may be flakey or you may have
    > a duff device driver.


    My hardware is certainly not flakey. I have prime95 installed on all my
    machines and have *three* boot floppies of memtest86+. All machines get
    checked at least monthly, overnight. (Or, in the case of the slower
    machines, as long as it takes to complete *all* Memtest86+ tests at least
    once, ('c' '2' '3' '0' to select all tests rather than the default). 27+
    hours for my 1.3GHz/384MB RAM)

    Could be a duff device driver I guess, I really don't know much about that
    stuff. More than your average bear but nowhere near as much as some people
    here. However nothing has been changed on the machine as far as drivers go
    for quite a while.

    I think that it may have been due to sunspot activity or cosmic rays etc.
    The re-boot fixed it and then, just because it's been three weeks or so
    since I ran it, Prime95 is running now. four and a half hours and counting.
    Memory errors (as opposed to CPU errors due to overheating/underpowering)
    seem to show up quite quickly in Prime95 IME, It's running Memtest86 that
    takes the time.

    sigverif told me my files have been scanned and verified as digitally
    signed. I didn't select the advanced option.

    However this installation is over 18 months old. I'm hoping to save up for a
    bigger HDD (and move this 80GB one down the chain). IF/when I get one I'm
    tempted to do a complete reinstall rather than a clone. However, that's the
    only problem I've had in those 18 months believe it or not. Not one BSOD or
    unexplained reboot. XP pro, now sp2.
    --
    ~misfit~
    ~misfit~, Sep 8, 2005
    #9
  10. ~misfit~

    Mercury Guest

    I actually was suggesting that to Peter....

    "~misfit~" <> wrote in message
    news:4320015a$...
    > Tim wrote:
    >
    > <Snippety do-dah>
    >
    >> That's my way of recommending memtest86 / prime95 and checking your
    >> device drivers - run sigverif. Your h/w may be flakey or you may have
    >> a duff device driver.

    >
    > My hardware is certainly not flakey. I have prime95 installed on all my
    > machines and have *three* boot floppies of memtest86+. All machines get
    > checked at least monthly, overnight. (Or, in the case of the slower
    > machines, as long as it takes to complete *all* Memtest86+ tests at least
    > once, ('c' '2' '3' '0' to select all tests rather than the default). 27+
    > hours for my 1.3GHz/384MB RAM)
    >
    > Could be a duff device driver I guess, I really don't know much about that
    > stuff. More than your average bear but nowhere near as much as some people
    > here. However nothing has been changed on the machine as far as drivers go
    > for quite a while.
    >
    > I think that it may have been due to sunspot activity or cosmic rays etc.
    > The re-boot fixed it and then, just because it's been three weeks or so
    > since I ran it, Prime95 is running now. four and a half hours and
    > counting. Memory errors (as opposed to CPU errors due to
    > overheating/underpowering) seem to show up quite quickly in Prime95 IME,
    > It's running Memtest86 that takes the time.
    >
    > sigverif told me my files have been scanned and verified as digitally
    > signed. I didn't select the advanced option.
    >
    > However this installation is over 18 months old. I'm hoping to save up for
    > a bigger HDD (and move this 80GB one down the chain). IF/when I get one
    > I'm tempted to do a complete reinstall rather than a clone. However,
    > that's the only problem I've had in those 18 months believe it or not. Not
    > one BSOD or unexplained reboot. XP pro, now sp2.
    > --
    > ~misfit~
    >
    Mercury, Sep 8, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ringo
    Replies:
    5
    Views:
    1,224
    ringo
    Dec 13, 2004
  2. Brian H¹©

    Hijacking a thread

    Brian H¹©, Jul 6, 2003, in forum: Computer Support
    Replies:
    19
    Views:
    780
  3. Bob Brister

    Hijacking

    Bob Brister, May 22, 2004, in forum: Computer Support
    Replies:
    16
    Views:
    985
    St?phane
    Jun 9, 2004
  4. Replies:
    3
    Views:
    837
    no way
    Aug 2, 2004
  5. Broom Hilda

    Hijacking detected

    Broom Hilda, Oct 10, 2005, in forum: Computer Support
    Replies:
    6
    Views:
    4,301
    zarathustra
    Oct 14, 2005
Loading...

Share This Page