Re: [pygame] encrypt/decrypt zip/unzip
i figured out a better way. All the data is written to a dictionary which in turn written to a py file. All the py file are compiled and and are INSIDE the exe. So I deliver ONLY 1 exe. everything including fonts are inside the exe. :) On Sat, Oct 18, 2014 at 5:10 AM, Stuart Axon stu.axon+pyg...@gmail.com wrote: You may as well use some normal encryption using some lib, this zipped method is a little odd. .. unless you want something to get kids into cracking software, that smart kids will break open ? (Which is fine too). On 26 August 2014 14:20, diliup gabadamudalige dili...@gmail.com wrote: :) please don't get upset or angry. There is no need for that. :) i am writing this software ONLY for windows. it is a music teaching software. Thanks for the support. I have learnt a lot from these forums. On Tue, Aug 26, 2014 at 6:40 PM, Dan Uznanski duznan...@gmail.com wrote: This is ridiculous. Your proposed measures 1. Disrupt normal computer operation far beyond any normal use case would dictate, and 2. Do not prevent your stated unwanted behavior. There are lots of programs out there that capture screenshots and video without using the clipboard; on some systems (mac, for one) these are the default. You've demanded a blood draw to get in the front door but the side entrance is wide open and wheelchair accessible. On Aug 26, 2014 8:47 AM, diliup gabadamudalige dili...@gmail.com wrote: Hi Alec, No offence to you or to anyone who may think contrary, but disrupting computer operation is not what this does.Sometimes when I am writing things to my DVD burner windows doesn't respond normally. The normal operation of windows is disrupted. So what is the malware here? There are many other situations like that. The meaning of the word malicious is intent to harm. So malicious software is software is software written with the intention of harming other software or what ever. My program is a music teaching software and the reason I disable certain keys after the user is informed is to prevent certain unwanted actions like screen copying. SO if they want to capture any screens while running an education program which has informed them that they can't capture screens while it is running is a bit strange. Everything is returned to normal once the program is exited. :) So not malware. On Tue, Aug 26, 2014 at 5:41 PM, Alec Bennett wrybr...@gmail.com wrote: doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here:
Re: [pygame] encrypt/decrypt zip/unzip
You may as well use some normal encryption using some lib, this zipped method is a little odd. .. unless you want something to get kids into cracking software, that smart kids will break open ? (Which is fine too). On 26 August 2014 14:20, diliup gabadamudalige dili...@gmail.com wrote: :) please don't get upset or angry. There is no need for that. :) i am writing this software ONLY for windows. it is a music teaching software. Thanks for the support. I have learnt a lot from these forums. On Tue, Aug 26, 2014 at 6:40 PM, Dan Uznanski duznan...@gmail.com wrote: This is ridiculous. Your proposed measures 1. Disrupt normal computer operation far beyond any normal use case would dictate, and 2. Do not prevent your stated unwanted behavior. There are lots of programs out there that capture screenshots and video without using the clipboard; on some systems (mac, for one) these are the default. You've demanded a blood draw to get in the front door but the side entrance is wide open and wheelchair accessible. On Aug 26, 2014 8:47 AM, diliup gabadamudalige dili...@gmail.com wrote: Hi Alec, No offence to you or to anyone who may think contrary, but disrupting computer operation is not what this does.Sometimes when I am writing things to my DVD burner windows doesn't respond normally. The normal operation of windows is disrupted. So what is the malware here? There are many other situations like that. The meaning of the word malicious is intent to harm. So malicious software is software is software written with the intention of harming other software or what ever. My program is a music teaching software and the reason I disable certain keys after the user is informed is to prevent certain unwanted actions like screen copying. SO if they want to capture any screens while running an education program which has informed them that they can't capture screens while it is running is a bit strange. Everything is returned to normal once the program is exited. :) So not malware. On Tue, Aug 26, 2014 at 5:41 PM, Alec Bennett wrybr...@gmail.com wrote: doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note
Re: [pygame] encrypt/decrypt zip/unzip
doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com wrote: Thanks for the
Re: [pygame] encrypt/decrypt zip/unzip
Hi Alec, No offence to you or to anyone who may think contrary, but disrupting computer operation is not what this does.Sometimes when I am writing things to my DVD burner windows doesn't respond normally. The normal operation of windows is disrupted. So what is the malware here? There are many other situations like that. The meaning of the word malicious is intent to harm. So malicious software is software is software written with the intention of harming other software or what ever. My program is a music teaching software and the reason I disable certain keys after the user is informed is to prevent certain unwanted actions like screen copying. SO if they want to capture any screens while running an education program which has informed them that they can't capture screens while it is running is a bit strange. Everything is returned to normal once the program is exited. :) So not malware. On Tue, Aug 26, 2014 at 5:41 PM, Alec Bennett wrybr...@gmail.com wrote: doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the
Re: [pygame] encrypt/decrypt zip/unzip
This is ridiculous. Your proposed measures 1. Disrupt normal computer operation far beyond any normal use case would dictate, and 2. Do not prevent your stated unwanted behavior. There are lots of programs out there that capture screenshots and video without using the clipboard; on some systems (mac, for one) these are the default. You've demanded a blood draw to get in the front door but the side entrance is wide open and wheelchair accessible. On Aug 26, 2014 8:47 AM, diliup gabadamudalige dili...@gmail.com wrote: Hi Alec, No offence to you or to anyone who may think contrary, but disrupting computer operation is not what this does.Sometimes when I am writing things to my DVD burner windows doesn't respond normally. The normal operation of windows is disrupted. So what is the malware here? There are many other situations like that. The meaning of the word malicious is intent to harm. So malicious software is software is software written with the intention of harming other software or what ever. My program is a music teaching software and the reason I disable certain keys after the user is informed is to prevent certain unwanted actions like screen copying. SO if they want to capture any screens while running an education program which has informed them that they can't capture screens while it is running is a bit strange. Everything is returned to normal once the program is exited. :) So not malware. On Tue, Aug 26, 2014 at 5:41 PM, Alec Bennett wrybr...@gmail.com wrote: doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their
Re: [pygame] encrypt/decrypt zip/unzip
:) please don't get upset or angry. There is no need for that. :) i am writing this software ONLY for windows. it is a music teaching software. Thanks for the support. I have learnt a lot from these forums. On Tue, Aug 26, 2014 at 6:40 PM, Dan Uznanski duznan...@gmail.com wrote: This is ridiculous. Your proposed measures 1. Disrupt normal computer operation far beyond any normal use case would dictate, and 2. Do not prevent your stated unwanted behavior. There are lots of programs out there that capture screenshots and video without using the clipboard; on some systems (mac, for one) these are the default. You've demanded a blood draw to get in the front door but the side entrance is wide open and wheelchair accessible. On Aug 26, 2014 8:47 AM, diliup gabadamudalige dili...@gmail.com wrote: Hi Alec, No offence to you or to anyone who may think contrary, but disrupting computer operation is not what this does.Sometimes when I am writing things to my DVD burner windows doesn't respond normally. The normal operation of windows is disrupted. So what is the malware here? There are many other situations like that. The meaning of the word malicious is intent to harm. So malicious software is software is software written with the intention of harming other software or what ever. My program is a music teaching software and the reason I disable certain keys after the user is informed is to prevent certain unwanted actions like screen copying. SO if they want to capture any screens while running an education program which has informed them that they can't capture screens while it is running is a bit strange. Everything is returned to normal once the program is exited. :) So not malware. On Tue, Aug 26, 2014 at 5:41 PM, Alec Bennett wrybr...@gmail.com wrote: doesn't fall into the category. :) Not to beat a dead horse, but I respectfully disagree. Note the first criteria in the first line of your linked article: Malware, short for malicious software, is *any software used to disrupt computer operation*, gather sensitive information, or gain access to private computer systems.[1] https://en.wikipedia.org/wiki/Malware#cite_note-1 Your program clearly disrupts computer operation. Also was not referring to full screen mode. Not that it matters, but if you don't say what you're referring to, its hard for people to point out how your analogy is probably wrong. On Mon, Aug 25, 2014 at 10:49 PM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is
Re: [pygame] encrypt/decrypt zip/unzip
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. **
Re: [pygame] encrypt/decrypt zip/unzip
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 vxgmic...@gmail.com 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. **
Re: [pygame] encrypt/decrypt zip/unzip
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.garw...@gmail.com 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 vxgmic...@gmail.com 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
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 dili...@gmail.com 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.garw...@gmail.com 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 vxgmic...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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.garw...@gmail.com 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 vxgmic...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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.garw...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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
Re: [pygame] encrypt/decrypt zip/unzip
Also was not referring to full screen mode. On Tue, Aug 26, 2014 at 11:19 AM, diliup gabadamudalige dili...@gmail.com wrote: https://en.wikipedia.org/wiki/Malware doesn't fall into the category. :) On Tue, Aug 26, 2014 at 11:10 AM, Alec Bennett wrybr...@gmail.com wrote: some games lock up the os and you need to exit the game to have access to the os. I think you're referring to fullscreen, which doesn't actually lock up the OS, it just takes over the screen, and all functions of the OS are still as usual. And a critical difference is that fullscreen is functionally important to the program, and is very obvious when its happening, whereas disabling the clipboard is just, in my opinion, malevolent. On Mon, Aug 25, 2014 at 10:32 PM, diliup gabadamudalige dili...@gmail.com wrote: It is stated in the opening screen. some games lock up the os and you need to exit the game to have access to the os. Does that make the game a malware? On Tue, Aug 26, 2014 at 10:46 AM, Alec Bennett wrybr...@gmail.com wrote: If you're clearing the Windows clipboard, you might want to let the user know that. Very prominently. Otherwise your program is basically malware in my opinion. It's still, in my opinion, malware, but at least you'd be warning the user so they'd know that running your program will cripple their os while it's running. Or just don't do silly things like clear the clipboard... On Aug 25, 2014, at 9:40 PM, diliup gabadamudalige dili...@gmail.com wrote: Dear Vincent and Dan, All points taken positively. I'm still learning Python and all this help and advice is making me write better and more pythonic code. I will leave this path and continue on the one I started traversing. I thank you all very much. May you be well. On Tue, Aug 26, 2014 at 2:58 AM, Vincent Michel vxgmic...@gmail.com wrote: I agree with Dan. Also, there're some great answers over here: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code For instance I like this one: Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods. 1 - Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component. 2 - Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive. 3 - Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering. 4 - Offer customization at rates so attractive that they'd rather pay you to build and support the enhancements. [...] About py2exe, it is a really limited obfuscation cause it actually just stores the .pyc byte code files in a .zip archive. It means that you can unzip your .exe file and see what's inside, there's no protection at all. Though, the python byte code files offer a basic protection since you need to use some tools like uncompyle, pyretic or pycdc. 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. This seems so wrong man, what if the user is trying to copy/paste anything while your program is running on the background? 2014-08-25 23:06 GMT+02:00 Dan Uznanski duznan...@gmail.com: 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 dili...@gmail.com 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
