Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Application hijacking?

Reply
Thread Tools

Application hijacking?

 
 
~misfit~
Guest
Posts: n/a
 
      09-08-2005
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~


 
Reply With Quote
 
 
 
 
Peter Huebner
Guest
Posts: n/a
 
      09-08-2005
In article <431f8dc7$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Tim
Guest
Posts: n/a
 
      09-08-2005
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






 
Reply With Quote
 
~misfit~
Guest
Posts: n/a
 
      09-08-2005
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~


 
Reply With Quote
 
~misfit~
Guest
Posts: n/a
 
      09-08-2005
Peter Huebner wrote:
> In article <431f8dc7$(E-Mail Removed)>, (E-Mail Removed)
> 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~


 
Reply With Quote
 
~misfit~
Guest
Posts: n/a
 
      09-08-2005
~misfit~ wrote:
> Peter Huebner wrote:
>> In article <431f8dc7$(E-Mail Removed)>, (E-Mail Removed)
>> 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~


 
Reply With Quote
 
Peter Huebner
Guest
Posts: n/a
 
      09-08-2005
In article <dfo9hr$68c$(E-Mail Removed)>, (E-Mail Removed) 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
 
Reply With Quote
 
Tim
Guest
Posts: n/a
 
      09-08-2005
inline...

"Peter Huebner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) .co.nz...
> In article <dfo9hr$68c$(E-Mail Removed)>, (E-Mail Removed) 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



 
Reply With Quote
 
~misfit~
Guest
Posts: n/a
 
      09-08-2005
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~


 
Reply With Quote
 
Mercury
Guest
Posts: n/a
 
      09-08-2005
I actually was suggesting that to Peter....

"~misfit~" <(E-Mail Removed)> wrote in message
news:4320015a$(E-Mail Removed)...
> 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~
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Winform Application Configuration Deleted by Application lhak ASP .Net 0 10-23-2004 11:47 PM
Calling Windows application from Web application ASP .Net 1 11-02-2003 03:30 AM
What issue will HIT me hard when I convert an Access 2002 MDE application to Web Application? Sean ASP .Net 2 08-07-2003 07:13 AM
Application folder not seeing namespace of the main application gh0st54 ASP .Net 0 07-04-2003 07:15 PM
How to inherit a base form in all application forms of an asp.net application varun varun ASP .Net 0 07-03-2003 08:58 AM



Advertisments