[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] encrypt/decrypt zip/unzip



Why bother? ÂThe average user won't care, the skilled users will see through your ruse like it's plastic wrap, and the ones who care but aren't that good will just find out what the skilled users did on the internet. ÂThe only thing you do by adding obfuscation is make it a little bit more of a pain for others to modify and improve your program, and make it a lot more of a pain for you to test your program.


On Mon, Aug 25, 2014 at 4:04 PM, diliup gabadamudalige <diliupg@xxxxxxxxx> wrote:
Thanks for the responses.
Firstly I am a bit amused that everybody assumes that I am writing some kind of game. I never mentioned any game. Is it because of Pygame? :) :)
I am using Pygame as my graphic interface because it is easy to display all graphics and music (with some MIDI) using Pygame. Incidentally I am writing a music teaching software.

I use maketrans with a code string and then XOR the result using another string and then finally base64 it before writing it to disk. So all files look like ->ÂCSVT121rI_OQt%BIc.@lm and even if someone duoble click or change the file ext they can not open the file in anything other than a text file editor.

If we keep the worst case scenarios out my majority users would be average computer users and I doubt somone taking the trouble to reverse engineer this software which is absolutely unknown. Maybe they will do so if it gets world famous ( :-) ) but then I will hire a professional team to encrypt it or I will use a dongle protection. But right now I am trying to close the files from prying eyes. When compiled with py2exe all the py files are strung together and one exe file is formed but all the assets remain in the folder with the same names inside the folder where the exe is. So anyone can simply copy the files and the text inside. But this way they have no access as the zip file is encrypted. If they crack that open then all the files are encrypted and the encrypted password is in another py file inside the exe.Â
Isn't this some kind of protection against no protection at all? I also clear the windows clipboard on every run of the main program loop thus preventing the user from taking screen grabs with print screen., These are taking into account THE THE AVERAGE USER.
Considering the average user are the precautions I have taken fair? What do you think?





On Mon, Aug 25, 2014 at 9:52 PM, Noel Garwick <noel.garwick@xxxxxxxxx> wrote:
Diliup,

My understanding is that anything you load into memory can be dumped. ÂSo if you're just using this to load all game assets at startup, people could extract the assets by duping what the interpreter has loaded into memory (the copies of the unencrypted files).


On Mon, Aug 25, 2014 at 11:52 AM, Vincent Michel <vxgmichel@xxxxxxxxx> wrote:
"the password is obfuscated and saved to a py file"
I'm curious about this part, how would you do that?
Do you plan to distribute only your byte code and hope that no one will
reverse it?

Also, why do you need a double encryption? If you want to prevent people
from browsing your package to find the end screen or whatever, isn't
your first encryption enough?

Anyway I think it's an interesting question, I mean, how important is it
to obfuscate game data.

Vincent

On Mon, 2014-08-25 at 19:38 +0530, diliup gabadamudalige wrote:
> Having experimented with various methods to obfuscate image, audio and
> text files, store them in a zip file pw protect and then retrieving on
> demand I finally did this.
>
>
> coder= a long string with a lot of characters ( written in a separate
> py file)
>
>
> strA = XOR(from_disk.read(), coder)
> str1 = XOR(strA,another_coder))
>
>
> encryption twice to obfuscate even more.
>
>
> with open(code_to_dir, "wb") as to_disk:
> to_disk.write(str1)
>
>
> then i used win rar to write these files to disk as a pw protected zip
> file with store as the comp. method.
>
>
> the password is obfuscated and saved to a py file
>
>
> Retrieving the files from inside the zip file was the only hitch as
> the python extract routine took a long time.
>
>
> this was solved by a great package at
> https://pypi.python.org/pypi/czipfile#downloads
>
>
> retrieval time increase by nearly/more than/almost 200 %.
>
>
> I would like to have your input on the above.
>
>
>
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.diliupg.com/
>
> **********************************************************************************************
> This e-mail is confidential. It may also be legally privileged. If you
> are not the intended recipient or have received it in error, please
> delete it and all copies from your system and notify the sender
> immediately by return e-mail. Any unauthorized reading, reproducing,
> printing or further dissemination of this e-mail or its contents is
> strictly prohibited and may be unlawful. Internet communications
> cannot be guaranteed to be timely, secure, error or virus-free. The
> sender does not accept liability for any errors or omissions.
> **********************************************************************************************
>
>






--
Diliup Gabadamudalige

http://www.diliupg.com
http://soft.diliupg.com/

**********************************************************************************************
This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
**********************************************************************************************