|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Announcements
Chapters
Services
Feature Zones
|
The problem descriptionIt can often be preferable for developers to store application images in separate image files, because it makes the construction and the maintenance of the application considerably easier. For example, using external images usually facilitates the cooperation between the programmer and the GUI designer, accommodates the localization and the use of themes, and also makes the updating procedure easier and faster. On the other hand, having separate image files makes it easier for unauthorized persons, to change the appearance of the application, which is often unacceptable. Someone could add here that, in the case of the external image files, there is also a danger of stealing the GUI images. In my opinion, this is not an important issue (at least, not for still images), since these images are going to be displayed on the screen eventually, and screen captures are very easy to do. Hence, stealing the GUI images can almost never be avoided. The proposed solution and the basic design decisionsThe most obvious solution in order to use external images and also avoid the dangers described above, is to encrypt the image data. However, encryption will introduce two new problems to the image loading procedure. It will make this procedure much more complicated and slower. Since loading speed and simplicity are very important issues in my case, I have made the following design decisions:
As a result of the above design decisions, the encrypted image will be easily recognizable (only some pixel rows will be encrypted), but it would be difficult to reuse it in another application, and even more difficult to replace or modify it in an existing application. The code implementation and usageAll my implementation code resides in the bool CImgCrypt::EncryptDIBSection(HBITMAP hbitmap, unsigned encryptedHeight, unsigned unencryptedHeight) bool CImgCrypt::DecryptDIBSection(HBITMAP hbitmap, unsigned encryptedHeight, unsigned unencryptedHeight) Specifically, the CImgCrypt imgCryptEngine("blowfish-key", 12); HBITMAP hBitmap = (HBITMAP)LoadImage(NULL, "image.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION | LR_DEFAULTSIZE); imgCryptEngine.DecryptDIBSection(hBitmap, 3, 6); I hope that this work will be helpful for you. In the download section, you will also find a demo application that provides a more "live" demonstration of what I have described in this article. Thank you for reading this. AcknowledgmentsI have based this work on the BlowFish implementation of George Anescu [1], and I have also used the Future plans
History
References
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||