Can extra processing threads help in this case?
in [MFC]
|
From: Joseph M. Newcomer on 30 Mar 2010 14:02 See below... On Tue, 30 Mar 2010 11:54:23 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:5c44r5lqvcragf94iskh3pm920ki4vs7bl(a)4ax.com... >> See below... >> On Mon, 29 Mar 2010 22:14:38 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>message news:tvu1r5pvuptd186f0jd2geuo1fk97ttdm0(a)4ax.com... >>>> See below... >>>> On Sun, 28 Mar 2010 22:42:28 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>>Not the ISP case, that is a distinctly different case. >>>>>A Webserver rented to the client at the client's site. >>>>>A Webserver rented to the client at the client's site. >>>>>A Webserver rented to the client at the client's site. >>>>>A Webserver rented to the client at the client's site. >>>> **** >>>> OK, there is NO way to protect the contents of the >>>> machine. Only increase the >>>> inconvenience to the person attempting to attack the >>>> machine. >>>> >>>> An encrypted hard drive would be a start. Seagate has a >>>> line of hard drives that support >>>> on-drive encryption. Of course, this wouldn't stop me >>>> from stealing your code, but it is >>>> a start for people less sophisticated than I am. It is >>>> likey that anyone who wants to >>>> steal your code is more experienced at attacking >>>> machines >>>> than I am, so while I might >>>> require a day, they might require single-digit minutes. >>>> And at not point is "opening" the >>>> machine required. As I said, even if it is sealed in a >>>> concrete enclosure or other >>>> technology enclosure (e.g., molded epoxy), the network >>>> cable coming out is a huge security >>>> hole. Most experts in cracking will walk right through >>>> it >>>> without even slowing down. So >>>> the location of the box doesn't really matter. Or are >>>> you >>>> so naive that you think that >>>> your web server is itself secure? Real people who run >>>> real Web servers know this is not >>>> true. >>>> **** >>>>> >>>>>I am attempting to come up with an entirely new basis of >>>>>copy protection where nothing that currently exists is >>>>>at >>>>>all comparable. >>>> **** >>>> That's for sure. Essentially, you are asking again for >>>> the impossible. >>>> **** >>> >>>Not quite since I already have it all figured out. The >>>only >>>piece that could use improvement is a way to make physical >>>access to the inside of the physical machine as close to >>>impossible without detection. I have this figured out too, >>>but my solution is more cumbersome than I would like. Got >>>any ideas on this? >> **** >> The "impossible" part is that you have equated "no >> physical access to the inside of the >> computer" with "this is a solution to not making it >> possible to steal software". > >There you go again making false assumptions, you do that a >lot. I never said that and I never meant that. "no physical >access to the inside of the computer" as I clearly stated >and you intentionally misconstrued is only a single element >of the overall plan to prevent software theft. **** You are right; you only indicated that you wanted to make it difficult to open the computer without detection. This leads to the conclusion that you thought preventing opening the computer was actually going to protect your software. **** > >> >> In other words, you have hypothesized, contradictory to >> all existing evidence, that it is >> "impossible" to steal software if you cannot open the >> machine up. Since it is > >And you go on and on, on the basis of you false >assumption... **** I wouldn't even worry about opening the computer; instead, I would worry about how to protect the software to prevent it running on another machine, and I know that only the hardware-assisted copy-peotection schemes, such as the HASP, which use USB dongles with challenge-response encryption systems, are actually reliable. joe **** > >What if the only possible access to the machine was through >port 443? **** HTTPS/SSL? Actually, not much would change. it just adds a little more effort to the problem of cracking. The experts already know how to get around it. Do you know the role of port 443, really? Do you know what it promises? What it delivers? Do you know what HTTPS really is? Have you read RFC 2818? Or RFC 2246? And what "protections" do you think you get, other than encrypted data transfer? Explain how encrypted data transfer prevents me from exploiting a buffer overrun in the server? Or invoking an insecure ActiveVirus control? Or accomplishing any other exploit? Have you even READ about how exploits work? Again, maybe I'm just biased by my years of studying computer security, but I don't think much of the idea; it only authenticates a sender/receiver transfer, and encrypts the data, but nothing else. You have a lot to learn. joe **** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 30 Mar 2010 14:39 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:gud4r51e7ii7e8ja9ma3tcno502uu4k4fu(a)4ax.com... > See below... > On Tue, 30 Mar 2010 11:54:23 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:5c44r5lqvcragf94iskh3pm920ki4vs7bl(a)4ax.com... >>> See below... >>> On Mon, 29 Mar 2010 22:14:38 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>message >>>>news:tvu1r5pvuptd186f0jd2geuo1fk97ttdm0(a)4ax.com... >>>>> See below... >>>>> On Sun, 28 Mar 2010 22:42:28 -0500, "Peter Olcott" >>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>> >>>>>>Not the ISP case, that is a distinctly different case. >>>>>>A Webserver rented to the client at the client's site. >>>>>>A Webserver rented to the client at the client's site. >>>>>>A Webserver rented to the client at the client's site. >>>>>>A Webserver rented to the client at the client's site. >>>>> **** >>>>> OK, there is NO way to protect the contents of the >>>>> machine. Only increase the >>>>> inconvenience to the person attempting to attack the >>>>> machine. >>>>> >>>>> An encrypted hard drive would be a start. Seagate has >>>>> a >>>>> line of hard drives that support >>>>> on-drive encryption. Of course, this wouldn't stop me >>>>> from stealing your code, but it is >>>>> a start for people less sophisticated than I am. It >>>>> is >>>>> likey that anyone who wants to >>>>> steal your code is more experienced at attacking >>>>> machines >>>>> than I am, so while I might >>>>> require a day, they might require single-digit >>>>> minutes. >>>>> And at not point is "opening" the >>>>> machine required. As I said, even if it is sealed in >>>>> a >>>>> concrete enclosure or other >>>>> technology enclosure (e.g., molded epoxy), the network >>>>> cable coming out is a huge security >>>>> hole. Most experts in cracking will walk right >>>>> through >>>>> it >>>>> without even slowing down. So >>>>> the location of the box doesn't really matter. Or are >>>>> you >>>>> so naive that you think that >>>>> your web server is itself secure? Real people who run >>>>> real Web servers know this is not >>>>> true. >>>>> **** >>>>>> >>>>>>I am attempting to come up with an entirely new basis >>>>>>of >>>>>>copy protection where nothing that currently exists is >>>>>>at >>>>>>all comparable. >>>>> **** >>>>> That's for sure. Essentially, you are asking again >>>>> for >>>>> the impossible. >>>>> **** >>>> >>>>Not quite since I already have it all figured out. The >>>>only >>>>piece that could use improvement is a way to make >>>>physical >>>>access to the inside of the physical machine as close to >>>>impossible without detection. I have this figured out >>>>too, >>>>but my solution is more cumbersome than I would like. >>>>Got >>>>any ideas on this? >>> **** >>> The "impossible" part is that you have equated "no >>> physical access to the inside of the >>> computer" with "this is a solution to not making it >>> possible to steal software". >> >>There you go again making false assumptions, you do that a >>lot. I never said that and I never meant that. "no >>physical >>access to the inside of the computer" as I clearly stated >>and you intentionally misconstrued is only a single >>element >>of the overall plan to prevent software theft. > **** > You are right; you only indicated that you wanted to make > it difficult to open the > computer without detection. This leads to the conclusion > that you thought preventing > opening the computer was actually going to protect your > software. > **** >> >>> >>> In other words, you have hypothesized, contradictory to >>> all existing evidence, that it is >>> "impossible" to steal software if you cannot open the >>> machine up. Since it is >> >>And you go on and on, on the basis of you false >>assumption... > **** > I wouldn't even worry about opening the computer; instead, > I would worry about how to > protect the software to prevent it running on another > machine, and I know that only the > hardware-assisted copy-peotection schemes, such as the > HASP, which use USB dongles with > challenge-response encryption systems, are actually > reliable. > joe > **** > >> >>What if the only possible access to the machine was >>through >>port 443? > **** > HTTPS/SSL? Actually, not much would change. it just adds > a little more effort to the > problem of cracking. The experts already know how to get > around it. Do you know the role > of port 443, really? Do you know what it promises? What > it delivers? Do you know what > HTTPS really is? Have you read RFC 2818? Or RFC 2246? > And what "protections" do you > think you get, other than encrypted data transfer? > Explain how encrypted data transfer > prevents me from exploiting a buffer overrun in the > server? Or invoking an insecure > ActiveVirus control? Or accomplishing any other exploit? > Have you even READ about how > exploits work? Again, maybe I'm just biased by my years > of studying computer security, > but I don't think much of the idea; it only authenticates > a sender/receiver transfer, and > encrypts the data, but nothing else. You have a lot to > learn. > joe Remember how we met? (In a 2005 email, about this article of yours) http://groups.google.com:80/group/microsoft.public.vc.mfc/msg/74db496855f60a0f That said, there is almost no reliable way to send mouse clicks to an application; lots of people have tried this and failed. You are in the model of "I want to write a Windows scripting language", and it is nearly impossible to get right. I've been involved with at least two projects that failed miserably > > **** >> > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 30 Mar 2010 17:04 Peter Olcott wrote: > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in > message news:q3v3r594leecok45c018d1m5mcljg48i0i(a)4ax.com... >> >> On Mon, 29 Mar 2010 22:33:57 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>> message news:uk12r5die24557r1evjkvrqovj58qjvc9e(a)4ax.com... >>>> See below... >>>> On Sun, 28 Mar 2010 23:03:42 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>>> But you can run >>>>>> with virtual memory WITHOUT paging being a part of it, >>>>> How is that not like running an automobile's engine >>>>> without >>>>> any form of fuel? >>>> **** >>>> Because you are being dense and stupid. For example, a >>>> better analogy would be running an >>> Calling me stupid (an opinion) >> **** >> Actually, it is a demonstrated fact, as anyone who has >> been following this thread can >> attest. We keep telling you "X" and you keep saying "not >> X", not because you have any > > I kept telling you that I wanted a way to prevent page > faults, and you kept providing memory mapped files as the > solution, knowing that memory mapped files do not prevent > page faults, and also knowing that VirtualLock() does > prevent pages faults. So who is acting stupidly in this > case? You! And in every case! How much do you expect to lock? It changes constantly, you cited load requirements of: - 1.5 GB - 4.0 GB - 5.0 GB - 2.0 TB How much do you plan to lock into memory? And why did microsoft invent AWE if it wasn't necessary and just use VirtualLock? -- HLS
From: Hector Santos on 30 Mar 2010 17:42 Joseph M. Newcomer wrote: >> Sure I have you just haven't gotten to it yet, email. I >> haven't got any more time for this discussion. I am >> convinced that I will get it right. I will get back to you >> on this when I am pretty sure that I have it right and you >> can double check my final design. > **** > Oh, in your fantasy world, email is a reliable delivery mechanism? It isn't out here in > the real world. And did you read Hector's comments on email acknowledgement (and he's far > more an expert on email than I am; all I know is that there are serious reliability issues > with email; the evidence is that people send me email which I never receive, and which > never even arrive at my ISP, although there is a record that they were sent). I am an active member and contributor of the SMTP working group/mailing list. I'm acknowledged in the RFC 5321 SMTP specification. http://tools.ietf.org/rfc/rfc5321.txt including acknowledged in the recently RFC 5598 endorsed creation of the "Internet Mail Architecture," document by one of the fathers of electronic mail, David Crocker: http://tools.ietf.org/rfc/rfc5598.txt I write and market a very highly integrated modern mail system and been doing mail systems since the 80s. I think I know maybe *a little* about this. :) > Apparently, you once read an article on email, and now believe you understand it > completely. Even your concept of a "veriiable email address" shows a degree of > cluenessness that is, alas, unsurprising. Abstract level thinking :) which is ok, if he had the integration right. For example, for all this fault tolerant talk, if the machine dies , how can it even send email? That means he needs an integrated redundancy that deals email. His database has to be on a remote server as well which I'm sure he didn't take into account He hasn't come close to realizing what are all the integration and communications issues are. He discovers another piece on a daily basis but just fails to see how things fit - which is OK, not everyone can be a good integrator, but Joesph, Mary, Charlie, Peter, John, Sally and David - this guy really wants to act like a maroon and as Delgado said, he really thinks he is serious! -- HLS
From: Hector Santos on 30 Mar 2010 17:55
Joseph M. Newcomer wrote: >> There you go again making false assumptions, you do that a >> lot. I never said that and I never meant that. "no physical >> access to the inside of the computer" as I clearly stated >> and you intentionally misconstrued is only a single element >> of the overall plan to prevent software theft. > You are right; you only indicated that you wanted to make it difficult to open the > computer without detection. This leads to the conclusion that you thought preventing > opening the computer was actually going to protect your software. A wise man once rhetorically asked, "Whats better? 49% of something or 100% of nothing?" Peter O. is one of those 100% of nothing guys. :) >> What if the only possible access to the machine was through >> port 443? > **** > HTTPS/SSL? Actually, not much would change. In fact, it means he is trying to hide something, hence become more attractive towards hacker exploration. -- HLS |