RAM Disk
in [MFC]
|
Prev: SetGet control input
Next: Copy constructor
From: vvf on 10 May 2010 04:36 Hi All, ==Problem statement== I have a MFC application that hosts a CDHtmlDialog window responsable with navigating through a series of HTML files stored on the local disk drive. The HTML files refer to some PNG images as well. I would like to ensure access to these HTML files and their associated PNG files ONLY through my application. In other words, I don't want the user to be able to use the local browser to open them and/or copy them somewhere else. ==End problem statement== ==Possible solution I thought of=== Attempt 1. Embed the HTML and image files into the executable. Outcome: Although I am able to embed the HTML files and navigate through them correctly using constructs such as <A HREF="res://MyApp.exe/#103">Test</A>, (where #103 is the resource number associated with the HTML linked via 'Test') I am unable to make references to the images within the HTML itself if these images are also embedded. Unfortunately, the images need to be protected as well as they represent proprietary diagrams and so on. Attempt 2. Encrypt/archive the HTML files and images. When the application runs, it decrypts/decompresses the HTML and images and when the user exits the application, it re-encrypts/re-compresses the files. Outcome: Works OK but the problem is that WHILE the application is running, the user may have access to the files. Furthermore, if anything goes wrong while shutting down the system, the files will be available. One solution would be to create a different desktop and run the application there locking up all ctrl+alt+del key combinations and so on. The problem with this approach is that the user will not have access to other applications while using mine and I don't want that to happen. ==End possible solutions== ===Question=== Given the information above, I thought that the best solution would be to start with all the files encrypted/compressed. When the user would run my application, I would create a RAM disk and decrypt/decompress the files there. Now, if anything would go wrong, it would be OK since the contents of the RAM disk will be lost upon restart or whatever. One problem though is that the user may see the RAM disk next to his/her regular disk drives and may copy the files that way. Therefore, my question is: Is there a way to create a RAM disk with MFC (or win32 in general) at user level that I could use just as a regular drive but that would not be visible to the user ? Seems a little far-fetched since I guess, logically, the RAM drive needs to behave exactly as a regular drive so that I can have my HTML files refer to it correctly. Can you please suggest other solutions to my problem if you can think of any better ones? ===End Question=== Thanks! __________ Information from ESET Smart Security, version of virus signature database 5099 (20100509) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: Goran on 10 May 2010 07:44 On May 10, 10:36 am, "vvf" <v...(a)vvf.com> wrote: > Hi All, > > ==Problem statement== > > I have a MFC application that hosts a CDHtmlDialog window responsable with > navigating through a series of HTML files stored on the local disk drive. > The HTML files refer to some PNG images as well. I would like to ensure > access to these HTML files and their associated PNG files ONLY through my > application. In other words, I don't want the user to be able to use the > local browser to open them and/or copy them somewhere else. This obviously begs the question: why? Why do you think that your users should put up with such a program? It's their computer, and it's their program. Bar any nefarious use, your users have the right to use the program the way they see fit. Not the way YOU see fit. > > ==End problem statement== > > ==Possible solution I thought of=== > > Attempt 1. Embed the HTML and image files into the executable. > > Outcome: Although I am able to embed the HTML files and navigate through > them correctly using constructs such as <A > HREF="res://MyApp.exe/#103">Test</A>, (where #103 is the resource number > associated with the HTML linked via 'Test') I am unable to make references > to the images within the HTML itself if these images are also embedded. > Unfortunately, the images need to be protected as well as they represent > proprietary diagrams and so on. If your "base" url is "res://MyApp.exe/myfile.html", then e.g. <img src="myimage.png...> should do it. BTW, using numeric identifiers is a PITA in this situation, don't toorture yourself. > > Attempt 2. Encrypt/archive the HTML files and images. When the application > runs, it decrypts/decompresses the HTML and images and when the user exits > the application, it re-encrypts/re-compresses the files. This is completely different from your first idea. With your first idea, there's no "protection" at all. Your user can still open the *.exe from a resource editor and see all your stuff. You seriously mixed apples and oranges. That said, question is: who are you protecting yourself from? There's no encription that's uncrackable when all "secrets" are known. In anything you write here, user has all on his machine, so there's no secret, and that's necessary for any strong encryption. What you are suggesting is no way to protect yourself from a determined hacker. Not in the slightest. If your users are just... people, perhaps you're safe. But in that case, chances are that simply putting your HTML in the *.exe is sufficient. > > Outcome: Works OK but the problem is that WHILE the application is running, > the user may have access to the files. Furthermore, if anything goes wrong > while shutting down the system, the files will be available. It is not very smart to even think about the file system. A determined hacker can step through your program with a debugger and see any operation you might want to do, all accesses to disk, all contents of your memory, everything. It's not hard at all. What kind of protection do you have then? Note that said hacker can easily wait for your code to start e.g. reading your image from the file AFTER it was decrypted and take it from memory. Here's the hard cold truth: unless you reach much, much deeper into DRM facilities of the system, you can't do what you want to do. But if your program was that "secret", you would be talking to Microsoft directly right now, you would not be asking a question on this newsgroup. I suggest that you simply drop your ideas. You have serious misconceptions about how computers work. > One solution > would be to create a different desktop and run the application there locking > up all ctrl+alt+del key combinations and so on. The problem with this > approach is that the user will not have access to other applications while > using mine and I don't want that to happen. Don't you see that these are serious contortions for your users? Is your program trying to create some value for your users, or only annoyances? Or is your code a way to steal something, or is there some other form of crime you're involved? Because, well-behaved and honest software has no need to hide from it's users the way you're describing (and it won't work either). > Given the information above, I thought that the best solution would be to > start with all the files encrypted/compressed. When the user would run my > application, I would create a RAM disk and decrypt/decompress the files > there. Now, if anything would go wrong, it would be OK since the contents of > the RAM disk will be lost upon restart or whatever. One problem though is > that the user may see the RAM disk next to his/her regular disk drives and > may copy the files that way. > > Therefore, my question is: Is there a way to create a RAM disk with MFC (or > win32 in general) at user level that I could use just as a regular drive but > that would not be visible to the user ? Seems a little far-fetched since I > guess, logically, the RAM drive needs to behave exactly as a regular drive > so that I can have my HTML files refer to it correctly. You should first understand that there is ultimately no way to hide anything from your user, not unless you dig into DRM. Goran.
From: vvf on 10 May 2010 08:13 "Goran" <goran.pusic(a)gmail.com> wrote in message news:22ebf116-55a4-4338-b0fc-55a347144285(a)a34g2000yqn.googlegroups.com... On May 10, 10:36 am, "vvf" <v...(a)vvf.com> wrote: > Hi All, > > ==Problem statement== > > I have a MFC application that hosts a CDHtmlDialog window responsable with > navigating through a series of HTML files stored on the local disk drive. > The HTML files refer to some PNG images as well. I would like to ensure > access to these HTML files and their associated PNG files ONLY through my > application. In other words, I don't want the user to be able to use the > local browser to open them and/or copy them somewhere else. > This obviously begs the question: why? The application is not free. A lot of the "value" that the application provides is in the HTML files (by means of their content). Therefore, I don't want the users to be able to just copy the HTML files, e-mail them or whatever they would do to "share" them. > Why do you think that your users should put up with such a program? My only requirement is for people to just execute the "main .exe" file of the program. This not only provides "context" for the HTML files, but is the only "supported" scenario for this application to run. I don't see why this would be such a huge problem as to wonder why a user should "put up" with something like this. > If your "base" url is "res://MyApp.exe/myfile.html", then e.g. <img > src="myimage.png...> should do it. BTW, using numeric identifiers is a > PITA in this situation, don't toorture yourself. Thanks for your suggestion. For some reason, I thought I tried that but it didn't work. I will try it again and come back with some results. > Attempt 2. Encrypt/archive the HTML files and images. When the application > runs, it decrypts/decompresses the HTML and images and when the user exits > the application, it re-encrypts/re-compresses the files. > This is completely different from your first idea. With your first > idea, there's no "protection" at all. Your user can still open the > *.exe from a resource editor and see all your stuff. You seriously > mixed apples and oranges. OK. I should have been a little bit more clear: > That said, question is: who are you protecting yourself from? I just don't want the HTML files to be copied somewhere else or be sent to somebody else. > What you are suggesting is no way to protect yourself from a > determined hacker. Not in the slightest. If your users are just... > people, perhaps you're safe. But in that case, chances are that simply > putting your HTML in the *.exe is sufficient. I don't have any intentions of protecting myself from a determined hacker. As you correctly noted, I just want to keep "an honest person"... honest. In other words, my users don't typically have any hacking/programming experience but they do know how to copy files. > One solution > would be to create a different desktop and run the application there > locking > up all ctrl+alt+del key combinations and so on. The problem with this > approach is that the user will not have access to other applications while > using mine and I don't want that to happen. > Or is your code a way to steal something, or is there some > other form of crime you're involved? Because, well-behaved and honest > software has no need to hide from it's users the way you're describing > (and it won't work either). Just because I don't want components of my program to be copied somewhere else doesn't mean that I am involved in who knows what forms of crimes/stealing/etc. :) I think you are exagerating. All I am trying to do is prevent users from copying the HTML files used by my application. > You should first understand that there is ultimately no way to hide > anything from your user, not unless you dig into DRM. Thank you for your suggestions Goran. vvf. __________ Information from ESET Smart Security, version of virus signature database 5101 (20100510) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: Joseph M. Newcomer on 10 May 2010 12:54 See below... On Mon, 10 May 2010 15:13:36 +0300, "vvf" <vvf(a)vvf.com> wrote: > >"Goran" <goran.pusic(a)gmail.com> wrote in message >news:22ebf116-55a4-4338-b0fc-55a347144285(a)a34g2000yqn.googlegroups.com... >On May 10, 10:36 am, "vvf" <v...(a)vvf.com> wrote: >> Hi All, >> >> ==Problem statement== >> >> I have a MFC application that hosts a CDHtmlDialog window responsable with >> navigating through a series of HTML files stored on the local disk drive. >> The HTML files refer to some PNG images as well. I would like to ensure >> access to these HTML files and their associated PNG files ONLY through my >> application. In other words, I don't want the user to be able to use the >> local browser to open them and/or copy them somewhere else. **** There is no way to do this. If the files appear as files, they are readable by anyone who has access to the file system, period. This is not something you can alter without creating a piece of malware, specifically, a rootkit attack. Look what happened to Sony! You do not want to do this! You choice to use CDHtmlDialog is probably the root of this problem. It requires the images be in files which are accessible from the file system. If you are this interested in protection, dump the CDHtmlDialog and go for a plain-vanilla CDialog where you can control what is going on, put the images in the resource segment of your executable, etc. I find CDHtmlDialog to be one of those Fundamentally Bad Ideas that got foisted off on us as if it made sense. **** > >> This obviously begs the question: why? > >The application is not free. A lot of the "value" that the application >provides is in the HTML files (by means of their content). >Therefore, I don't want the users to be able to just copy the HTML files, >e-mail them or whatever they would do to "share" them. **** You can't stop them. From your viewpoint, you have hit a severe defect in the CDHtmlDIalog design. Sorry, no fix. Either redo it as a plain-vanilla dialog, or figure out how to store the text in the resource segment. **** > >> Why do you think that your users should put up with such a program? > >My only requirement is for people to just execute the "main .exe" file of >the program. This not only provides "context" for the HTML files, >but is the only "supported" scenario for this application to run. I don't >see why this would be such a huge problem as to wonder why a user >should "put up" with something like this. **** No, I think the comment was that you want a way to prevent the user from accessing files in your directory. This is not going to happen, not in the current NTFS file system. You can argue that the CDHtmlDialog design is poor, or the notion of file protection needs to be extended so only an executing file can access files in its own directory, but these are deep and fundamental changes which you are unlikely to get from Microsoft **** > > >> If your "base" url is "res://MyApp.exe/myfile.html", then e.g. <img >> src="myimage.png...> should do it. BTW, using numeric identifiers is a >> PITA in this situation, don't toorture yourself. > >Thanks for your suggestion. For some reason, I thought I tried that but it >didn't work. I will try it again and come back with some results. > >> Attempt 2. Encrypt/archive the HTML files and images. When the application >> runs, it decrypts/decompresses the HTML and images and when the user exits >> the application, it re-encrypts/re-compresses the files. **** This is probably going to require capabilities not supported by CDHtmlDialog, and as soon as someone discovers what is going on, all they have to do is find out where the decrypted file is while the program is running! An exercise for a bright 12-year-old. **** > >> This is completely different from your first idea. With your first >> idea, there's no "protection" at all. Your user can still open the >> *.exe from a resource editor and see all your stuff. You seriously >> mixed apples and oranges. **** There is no protection from people who have the right tools and know how to use them. While you might use the resource segment to defeat said bright 12-year-old, it wouldn't stop most participants of this newsgroup, in fact, it wouldn't even slow them down! **** > >OK. I should have been a little bit more clear: > >> That said, question is: who are you protecting yourself from? > >I just don't want the HTML files to be copied somewhere else or be sent to >somebody else. **** As soon as they are "HTML files" you cannot stop this from happening! So why use CDHtmlDialog at all? **** > > >> What you are suggesting is no way to protect yourself from a >> determined hacker. Not in the slightest. If your users are just... >> people, perhaps you're safe. But in that case, chances are that simply >> putting your HTML in the *.exe is sufficient. > >I don't have any intentions of protecting myself from a determined hacker. >As you correctly noted, I just want to keep >"an honest person"... honest. In other words, my users don't typically have >any hacking/programming experience but >they do know how to copy files. **** Then don't use files. Use something else. Like a plain-vanilla CDialog-derived class! **** > >> One solution >> would be to create a different desktop and run the application there >> locking >> up all ctrl+alt+del key combinations and so on. The problem with this >> approach is that the user will not have access to other applications while >> using mine and I don't want that to happen. **** It would take me about 10 seconds to discover that what I had running was a P.O.S. and I would want my money back. If it was a free trial download, I would not buy it. **** > >> Or is your code a way to steal something, or is there some >> other form of crime you're involved? Because, well-behaved and honest >> software has no need to hide from it's users the way you're describing >> (and it won't work either). > >Just because I don't want components of my program to be copied somewhere >else doesn't mean >that I am involved in who knows what forms of crimes/stealing/etc. :) I >think you are exagerating. **** Then don't store your components as copyable files! The choice of CDHtmlDialog was probably a bad choice in the context of what you are trying to accomplish. **** > >All I am trying to do is prevent users from copying the HTML files used by >my application. **** You can't. **** > > >> You should first understand that there is ultimately no way to hide >> anything from your user, not unless you dig into DRM. > >Thank you for your suggestions Goran. **** What does any of this have to do with the concept of a RAM disk? Nothing whatsoever, as far as I can tell. joe **** > >vvf. > > > >__________ Information from ESET Smart Security, version of virus signature database 5101 (20100510) __________ > >The message was checked by ESET Smart Security. > >http://www.eset.com > > > 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 10 May 2010 13:04
Overall, IMO, and I say its an OPINION today, because YESTERDAY it would be against the LAW, to use a browser for local file access. This is just asking for trouble and you are facing that "SandBoxing" design question now. That is what is about - Sandboxing. If you are going to allow a browser client, specially its an embedded in your MFC application (it is still IE in backend), then you need to have Trust relationships and/or work with a Backend Server application which your URIs are related to a HTTP request and not some local URI source as file:// or res:// The latter approach is how we do it. You can create a local secured HTTP server to help serve your pages and resources and make your application CDHtmlDialog reference a local HTTP request. Otherwise, you will be facing the security issue that was always an engineering taboo until people starting to get the idea of running and loading data on the user's machine hence local file access. vvf wrote: > Hi All, > > ==Problem statement== > > I have a MFC application that hosts a CDHtmlDialog window responsable with > navigating through a series of HTML files stored on the local disk drive. > The HTML files refer to some PNG images as well. I would like to ensure > access to these HTML files and their associated PNG files ONLY through my > application. In other words, I don't want the user to be able to use the > local browser to open them and/or copy them somewhere else. > > ==End problem statement== > > > ==Possible solution I thought of=== > > Attempt 1. Embed the HTML and image files into the executable. > > Outcome: Although I am able to embed the HTML files and navigate through > them correctly using constructs such as <A > HREF="res://MyApp.exe/#103">Test</A>, (where #103 is the resource number > associated with the HTML linked via 'Test') I am unable to make references > to the images within the HTML itself if these images are also embedded. > Unfortunately, the images need to be protected as well as they represent > proprietary diagrams and so on. > > Attempt 2. Encrypt/archive the HTML files and images. When the application > runs, it decrypts/decompresses the HTML and images and when the user exits > the application, it re-encrypts/re-compresses the files. > > Outcome: Works OK but the problem is that WHILE the application is running, > the user may have access to the files. Furthermore, if anything goes wrong > while shutting down the system, the files will be available. One solution > would be to create a different desktop and run the application there locking > up all ctrl+alt+del key combinations and so on. The problem with this > approach is that the user will not have access to other applications while > using mine and I don't want that to happen. > > ==End possible solutions== > > ===Question=== > > Given the information above, I thought that the best solution would be to > start with all the files encrypted/compressed. When the user would run my > application, I would create a RAM disk and decrypt/decompress the files > there. Now, if anything would go wrong, it would be OK since the contents of > the RAM disk will be lost upon restart or whatever. One problem though is > that the user may see the RAM disk next to his/her regular disk drives and > may copy the files that way. > > Therefore, my question is: Is there a way to create a RAM disk with MFC (or > win32 in general) at user level that I could use just as a regular drive but > that would not be visible to the user ? Seems a little far-fetched since I > guess, logically, the RAM drive needs to behave exactly as a regular drive > so that I can have my HTML files refer to it correctly. > > Can you please suggest other solutions to my problem if you can think of any > better ones? > > ===End Question=== > > Thanks! > > > > > > > __________ Information from ESET Smart Security, version of virus signature database 5099 (20100509) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > |