Ben Sizer wrote: > Mike Meyer wrote: > > "Ben Sizer" <[EMAIL PROTECTED]> writes: > > > Decompyle (http://www.crazy-compilers.com/decompyle/ ) claims to be > > > pretty advanced. I don't know if you can download it any more to test > > > this claim though. > > > > No, it doesn't claim to be advanced. It claims to be good at what it > > does. There's no comparison with other decompilers at all. In > > particular, this doesn't give you any idea whether or not similar > > products exist for x86 or 68k binaries. > > That's irrelevant. We don't require a citable source to prove the > simple fact that x86 binaries do not by default contain symbol names > whereas Python .pyc and .pyo files do contain them. So any > decompilation of (for example) C++ code is going to lose all the > readable qualities, as well as missing any symbolic constants, > enumerations, templated classes and functions, macros, #includes, > inlined functions, typedefs, some distinctions between array indexing > and pointer arithmetic, which inner scope a simple data variable is > declared in, distinctions between functions/member functions declared > as not 'thiscall'/static member functions, const declarations, etc. > > > I've dealt with some very powerfull disassemblers and > > decompilers, but none of them worked on modern architectures. > > You can definitely extract something useful from them, but without > symbol names you're going to have to be working with a good debugger > and a decent knowledge of how to use it if you want to find anything > specific. Whereas Python could give you something pretty obvious such > as: > > 6 LOAD_FAST 0 (licensed) > 9 JUMP_IF_FALSE 9 (to 21) > > > > It makes a lot of difference when you're hunting around for something > > > or trying to understand a bit of code. Python bytecode (or at least, > > > the output from dis) is also a lot more straightforward than x86 or 68K > > > assembly to decipher. > > > > I'm not convinced of the former. I'll grant you half of the > > latter. 68K machine language is fairly straightforward. On the other > > hand, it's also seems to be irrelevant. What platform are you > > developing for that's still based on the 68K? > > There are several embedded/portable devices based on 68K derivatives. > That's not really the point though. I chose 68K assembly as an example > as it's considered to be simpler than x86 assembly, yet it's still > significantly more complex and less readable than the output from > dis.dis() > > > > The term I should > > > probably have used was 'distribute usable additional copies'. > > > > My question still stands, though - and unanswered. > > I'm not really sure where we're going here. I have made the point that > I am not obliged to make my software copyable to facilitate your right > to copy it any more than any given newspaper is obliged to publish you > to facilitate your right to free speech. Therefore I find it hard to > see how anything is infringing upon a right here. > > My interest lies in being able to use encrypted data (where 'data' can > also include parts of the code) so that the data can only be read by my > Python program, and specifically by a single instance of that program. > You would be able to make a backup copy (or 20), you could give the > whole lot to someone else, etc etc. I would just like to make it so > that you can't stick the data file on Bittorrent and have the entire > world playing with data that was only purchased once. > > > But we can be > > explicit if you want: How do you do that without requiring that your > > software be given special consideration in the distaster recovery and > > preparedness planning? > > I should state that I am not at all claiming a "one size fits all" > policy for software development. Firstly, from a personal point of view > I am talking about simple consumer entertainment software which is not > mission critical or anything like it. For more important software, > there will surely be different expectations and requirements. In my > case, providing a free download of any lost executables or data upon > presentation of a legitimate license key should be adequate. > > -- > Ben Sizer.
Do developers, when writing code consider how protected their code will be when considering what language they will write it in i.e ease of use, speed of language, maintainability and 'obfuscatability' ? Is the problem of protecting or otherwise encrypting portions of code a showstopper for some companies/individuals when using bytecode interpreted languages? I'm asking coz i don't have any real world/industrial basis to better understand the problem and factors involved when selling software - i'm just a student ********************************************************* petantik f00l http://petantik.blogsome.com - A Lucid Look at Reality -- http://mail.python.org/mailman/listinfo/python-list
