A friend of mine wrote his PhD dissertation on this topic in the late
1970s. I wonder how many patents will be invalidated because of his prior
art?
I will forward this to him; it might generate revenue for him as expert
witness. Do you know a URL I can point him to?
joe
xxxxx@flounder.com wrote:
> … Until we have CPU chips that run encrypted
> code streams, doing the decode with a private key during the instruction
> fetch cycle, software can be trivially reverse-engineered.
And for better or for worse, we are likely to have exactly that
technology within the year.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Also, of course, when this happens the OP’s question makes even less
sense, since only the encrypted binary will need to be on the file system!
joe
xxxxx@flounder.com wrote:
> … Until we have CPU chips that run encrypted
> code streams, doing the decode with a private key during the instruction
> fetch cycle, software can be trivially reverse-engineered.
And for better or for worse, we are likely to have exactly that
technology within the year.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
xxxxx@flounder.com wrote:
> … Until we have CPU chips that run encrypted code streams, doing
> the decode with a private key during the instruction fetch cycle,
> software can be trivially reverse-engineered.
And for better or for worse, we are likely to have exactly that technology
within the year.
I wonder how many viruses this will ultimately stop, and how much illegal software copying and reverse engineering it will prevent. I’m betting that long term it will be a number close to zero and in the end it means that debugging becomes harder, computers run hotter and slower than they need to, and my laptop runs for half as long.
James
> And for better or for worse, we are likely to have exactly that technology within the year.
Well, there are some examples of “innovations” like that failing to gain widespread public support while managing to get widespread resistance/criticism. MSFT Palladium, TRM chips, Intel unique CPU ID number are the very first examples that come to my mind. Certainly, attempts like that will be made again and again and again, always in the name of enhancing user security - this is out of question. The only question is how successful they are going to be…
Anton Bassov
On 3/2/2012 5:07 AM, xxxxx@hotmail.com wrote:
Hello,
I would like to load my driver from memory (in a buffer) without using the filesystem.
I search many time but I can’t find a way. Can you help me ?
Thanks,
To begin with, this is all way off the reservation, and not suitable for
use by the general public. That having been said, there is no native OS
support for loading driver (or other code) directly from memory, except
possibly from a RAM disk (which requires that you already have driver
code loaded into memory). The only way to accomplish this is to write
your own loader to load and relocate the code. If you can load the
driver into memory anywhere, it can be executed. Of course, you may
crash a certain percentage of systems, but oh well.
Have you considered using the GPU?
Regards,
g.