> Um, where I saw something like this? Ah, UNIX kernel which has to be relinked
after any driver
installation. Really user/administrator friendly.
The GENERIC (I’m about FreeBSD) kernel includes the drivers for most common
hardware. In most cases, it is fine.
People installing servers often build their own per-machine kernels, knowing
for sure that there will be no changes in this machine’s hardware for months.
Also Novell kernel; in fact, a several modules packed (with compression) to
one image.
No, it uses NLMs similar to Windows’s SYSs.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, July 27, 2004 9:52 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Driver File checksum
> Um, where I saw something like this? Ah, UNIX kernel which has to be relinked
after any driver
>installation. Really user/administrator friendly.
The GENERIC (I’m about FreeBSD) kernel includes the drivers for most common
hardware. In most cases, it is fine.
People installing servers often build their own per-machine kernels, knowing
for sure that there will be no changes in this machine’s hardware for months.
Good for servers but most Windows installations are workstations.
>Also Novell kernel; in fact, a several modules packed (with compression) to
one image.
No, it uses NLMs similar to Windows’s SYSs.
Well, I haven’t used Novell for long years and above was about 3.12. There already were NLMs but kernel (server.exe?) consisted from several NLMs packed to one image as I wrote. I mentioned it just because it is similar to what you suggested and still didn’t prevent change.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]
How paranoid are you? If you are extremely paranoid, then the following may
work.
- Compile a final version of the driver or program and all supporting
files that will be released.
- Rename them with a file extension that will not permit normal execution.
- Write a loader program or driver that will check the other files.
- Add to the loader program/driver the encrypted hashes of the files,
their names, and date/times. This will use a private key contained within a
smartcard.
- When loading the loader will read each file recomputing the hashes and
use the public key to decrypt the encrypted hash and compare.
- The loader can then start execution of the driver or program as desired.
Using RSA public key cryptography will stop forging of signatures. It will
leave the loader program/driver as being the only thing that can be replaced
with a virus. A driver can be hidden within a program as DeviceTree does,
but it requires administrator rights to do this. The load could decrypt the
real driver/program if desired to slow down reverse engineering.
“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> Since you have to have the certificate used to sign the driver.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
> “PeterGV” wrote in message news:xxxxx@ntdev…
> > >
> > > Driver signing may trap this, or the hacker should sign his patched
> version +
> > > all satellite files once again. Is this correct ?
> > >
> >
> > If you are trying to ensure that the binary you ship is the binary that
> > gets installed, yes. Driver signing will catch this. As well as any
> > changes to the associated INF file.
> >
> > Peter
> > OSR
> >
> >
>
>
>
:-)))
How paranoid are you? If you are extremely paranoid, then the following may
work.
- Compile a final version of the driver or program and all supporting
files that will be released.
- Rename them with a file extension that will not permit normal execution.
- Write a loader program or driver that will check the other files.
- Add to the loader program/driver the encrypted hashes of the files,
their names, and date/times. This will use a private key contained within a
smartcard.
- When loading the loader will read each file recomputing the hashes and
use the public key to decrypt the encrypted hash and compare.
- The loader can then start execution of the driver or program as desired.
AND delete as quick a possible with extreme priority all decrypted files after they
were loaded. If not , a hacker could *collect* a marvellous set of files that he can
load by himself using common available tools. Not to mention the registry values
that must be “cleaned” once the driver has read them out …
It’s feasable ! :-))
Using RSA public key cryptography will stop forging of signatures. It will
leave the loader program/driver as being the only thing that can be replaced
with a virus. A driver can be hidden within a program as DeviceTree does,
but it requires administrator rights to do this. The load could decrypt the
real driver/program if desired to slow down reverse engineering.
“Gary G. Little” wrote in message
> news:xxxxx@ntdev…
> > Since you have to have the certificate used to sign the driver.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
> >
> > “PeterGV” wrote in message news:xxxxx@ntdev…
> > > >
> > > > Driver signing may trap this, or the hacker should sign his patched
> > version +
> > > > all satellite files once again. Is this correct ?
> > > >
> > >
> > > If you are trying to ensure that the binary you ship is the binary that
> > > gets installed, yes. Driver signing will catch this. As well as any
> > > changes to the associated INF file.
> > >
> > > Peter
> > > OSR
> > >
> > >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Esentially what this all comes down to is a cat and mouse game. Your trying
to create an unbeatable system, but it has one fatal flaw. It at some point
has to be an unencrypted, uncompressed, unpacked, normal executable code image
and as soon as its in memory, its vulnerable to patching. Basically you have
to make a comprimise and pick a point where your reasonably sure that no attempts
will be made, because if there is a correct way around it, there will be someone
to reverse it and make an incorrect way around it. No system is perfect and as
a result, every system is hackable.
asa
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christiaan
Ghijselinck
Sent: Tuesday, July 27, 2004 5:25 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Driver File checksum
:-)))
How paranoid are you? If you are extremely paranoid, then the following may
work.
- Compile a final version of the driver or program and all supporting
files that will be released.
- Rename them with a file extension that will not permit normal execution.
- Write a loader program or driver that will check the other files.
- Add to the loader program/driver the encrypted hashes of the files,
their names, and date/times. This will use a private key contained within a
smartcard.
- When loading the loader will read each file recomputing the hashes and
use the public key to decrypt the encrypted hash and compare.
- The loader can then start execution of the driver or program as desired.
AND delete as quick a possible with extreme priority all decrypted files after they
were loaded. If not , a hacker could *collect* a marvellous set of files that he can
load by himself using common available tools. Not to mention the registry values
that must be “cleaned” once the driver has read them out …
It’s feasable ! :-))
Using RSA public key cryptography will stop forging of signatures. It will
leave the loader program/driver as being the only thing that can be replaced
with a virus. A driver can be hidden within a program as DeviceTree does,
but it requires administrator rights to do this. The load could decrypt the
real driver/program if desired to slow down reverse engineering.
“Gary G. Little” wrote in message
> news:xxxxx@ntdev…
> > Since you have to have the certificate used to sign the driver.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
> >
> > “PeterGV” wrote in message news:xxxxx@ntdev…
> > > >
> > > > Driver signing may trap this, or the hacker should sign his patched
> > version +
> > > > all satellite files once again. Is this correct ?
> > > >
> > >
> > > If you are trying to ensure that the binary you ship is the binary that
> > > gets installed, yes. Driver signing will catch this. As well as any
> > > changes to the associated INF file.
> > >
> > > Peter
> > > OSR
> > >
> > >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@rivin.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Esentially what this all comes down to is a cat and mouse game. Your trying
to create an unbeatable system, but it has one fatal flaw. It at some point
has to be an unencrypted, uncompressed, unpacked, normal executable code image
and as soon as its in memory, its vulnerable to patching. Basically you have
to make a comprimise and pick a point where your reasonably sure that no attempts
will be made, because if there is a correct way around it, there will be someone
to reverse it and make an incorrect way around it. No system is perfect and as
a result, every system is hackable.
Are you very sure about that ? I am not . But , to be honest, if I try to find a solution
for a driver, I will not walk the way of building a “package” . The driver will have to defend
himself against hackery, as autarkic as possible. Just another joke : may be I could jump into
real mode , where no debugger can follow :-))) Then do *something* , for example decrypt
parts of my own code, and jump back into protected mode to the just decrypted code …
My primary question was not answered , but nevertheless, I will close this thread from my side …
asa
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christiaan
Ghijselinck
Sent: Tuesday, July 27, 2004 5:25 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Driver File checksum
:-)))
> How paranoid are you? If you are extremely paranoid, then the following may
> work.
>
> 1. Compile a final version of the driver or program and all supporting
> files that will be released.
> 2. Rename them with a file extension that will not permit normal execution.
> 3. Write a loader program or driver that will check the other files.
> 4. Add to the loader program/driver the encrypted hashes of the files,
> their names, and date/times. This will use a private key contained within a
> smartcard.
> 5. When loading the loader will read each file recomputing the hashes and
> use the public key to decrypt the encrypted hash and compare.
> 6. The loader can then start execution of the driver or program as desired.
AND delete as quick a possible with extreme priority all decrypted files after they
were loaded. If not , a hacker could *collect* a marvellous set of files that he can
load by himself using common available tools. Not to mention the registry values
that must be “cleaned” once the driver has read them out …
It’s feasable ! :-))
> Using RSA public key cryptography will stop forging of signatures. It will
> leave the loader program/driver as being the only thing that can be replaced
> with a virus. A driver can be hidden within a program as DeviceTree does,
> but it requires administrator rights to do this. The load could decrypt the
> real driver/program if desired to slow down reverse engineering.
>
> “Gary G. Little” wrote in message
> > news:xxxxx@ntdev…
> > > Since you have to have the certificate used to sign the driver.
> > >
> > > –
> > > Gary G. Little
> > > Seagate Technologies, LLC
> > >
> > > “PeterGV” wrote in message news:xxxxx@ntdev…
> > > > >
> > > > > Driver signing may trap this, or the hacker should sign his patched
> > > version +
> > > > > all satellite files once again. Is this correct ?
> > > > >
> > > >
> > > > If you are trying to ensure that the binary you ship is the binary that
> > > > gets installed, yes. Driver signing will catch this. As well as any
> > > > changes to the associated INF file.
> > > >
> > > > Peter
> > > > OSR
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rivin.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Although, having a CPU that supports execution-time public key
decryption of the instruction stream goes a long way. 
Chuck
----- Original Message -----
From: “Asa Yeamans”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, July 28, 2004 1:02 PM
Subject: RE: Re:[ntdev] Driver File checksum
> Esentially what this all comes down to is a cat and mouse game. Your
trying
> to create an unbeatable system, but it has one fatal flaw. It at some
point
> has to be an unencrypted, uncompressed, unpacked, normal executable
code image
> and as soon as its in memory, its vulnerable to patching. Basically
you have
> to make a comprimise and pick a point where your reasonably sure that
no attempts
> will be made, because if there is a correct way around it, there will
be someone
> to reverse it and make an incorrect way around it. No system is
perfect and as
> a result, every system is hackable.
>
> asa
> Well, I haven’t used Novell for long years and above was about 3.12. There
already were
NLMs but kernel (server.exe?) consisted from several NLMs packed to one image
as I wrote. I
mentioned it just because it is similar to what you suggested and still didn’t
prevent change.
NetWare 3 used dynamically loadable NLMs for disk controllers and network card
drivers.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
I agree.
The outbursts of creativity around security is really amazing, especially
given the fact that most security problems can be blocked by primitive
solutions like “never work as administrator”, “use firewalls or NATs”, “install
patches frequently” and “switch away the features in your apps which are known
to be unsecure”.
Following these 4 simple principles are enough to eliminate the need in
antivirus in Windows, for instance.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Asa Yeamans”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, July 28, 2004 10:02 AM
Subject: RE: Re:[ntdev] Driver File checksum
> Esentially what this all comes down to is a cat and mouse game. Your trying
> to create an unbeatable system, but it has one fatal flaw. It at some point
> has to be an unencrypted, uncompressed, unpacked, normal executable code
image
> and as soon as its in memory, its vulnerable to patching. Basically you have
> to make a comprimise and pick a point where your reasonably sure that no
attempts
> will be made, because if there is a correct way around it, there will be
someone
> to reverse it and make an incorrect way around it. No system is perfect and
as
> a result, every system is hackable.
>
> asa
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Christiaan
> Ghijselinck
> Sent: Tuesday, July 27, 2004 5:25 PM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Driver File checksum
>
>
>
> :-)))
>
>
> > How paranoid are you? If you are extremely paranoid, then the following
may
> > work.
> >
> > 1. Compile a final version of the driver or program and all supporting
> > files that will be released.
> > 2. Rename them with a file extension that will not permit normal
execution.
> > 3. Write a loader program or driver that will check the other files.
> > 4. Add to the loader program/driver the encrypted hashes of the files,
> > their names, and date/times. This will use a private key contained within
a
> > smartcard.
> > 5. When loading the loader will read each file recomputing the hashes and
> > use the public key to decrypt the encrypted hash and compare.
> > 6. The loader can then start execution of the driver or program as
desired.
>
> AND delete as quick a possible with extreme priority all decrypted files
after they
> were loaded. If not , a hacker could collect a marvellous set of files that
he can
> load by himself using common available tools. Not to mention the registry
values
> that must be “cleaned” once the driver has read them out …
>
> It’s feasable ! :-))
>
>
> > Using RSA public key cryptography will stop forging of signatures. It will
> > leave the loader program/driver as being the only thing that can be
replaced
> > with a virus. A driver can be hidden within a program as DeviceTree does,
> > but it requires administrator rights to do this. The load could decrypt
the
> > real driver/program if desired to slow down reverse engineering.
> >
> > “Gary G. Little” wrote in message
> > news:xxxxx@ntdev…
> > > Since you have to have the certificate used to sign the driver.
> > >
> > > –
> > > Gary G. Little
> > > Seagate Technologies, LLC
> > >
> > > “PeterGV” wrote in message news:xxxxx@ntdev…
> > > > >
> > > > > Driver signing may trap this, or the hacker should sign his patched
> > > version +
> > > > > all satellite files once again. Is this correct ?
> > > > >
> > > >
> > > > If you are trying to ensure that the binary you ship is the binary that
> > > > gets installed, yes. Driver signing will catch this. As well as any
> > > > changes to the associated INF file.
> > > >
> > > > Peter
> > > > OSR
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
xxxxx@compaqnet.be
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rivin.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, July 29, 2004 4:25 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Driver File checksum
> Well, I haven’t used Novell for long years and above was about 3.12. There
already were
>NLMs but kernel (server.exe?) consisted from several NLMs packed to one image
as I wrote. I
>mentioned it just because it is similar to what you suggested and still didn’t
prevent change.
NetWare 3 used dynamically loadable NLMs for disk controllers and network card
drivers.
Yes, there were standalone NLMs, too. We even used FTP and BOOTP servers loaded as NLMs (not from Novell). Still I resist on my original claim. I’m quite sure because unpacked and repacked kernel 
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]