Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
Alex Martelli wrote: > Ben Sizer <[EMAIL PROTECTED]> wrote: > > > I don't know. In terms of copy protection, popular off-the-shelf > > software is going to get cracked whether it's written in Python or x86 > > ASM, that much is true. But in terms of perhaps protecting innovative > > algorithms from competitors, or something similar, compilation into > > native code does a great job of hiding your work. Not a perfect job, > > but a good enough job. > > If they're truly worth protecting, they're worth reverse engineering. It's a sliding scale though. You don't need to be able to stop everybody to make it worthwhile. > Remember, the competition includes excellent programmers working in > countries where $10 an hour's salary is luxury and IP law enforcements > non-existent, so the cost to reveng is not as high as you might think. Whether $10 is a lot or a little is not as important as whether that $10 could be better spent. It's easy to drill down far enough to break copy protection but nowhere near as easy to derive a high level algorithm from the assembly language. So in the latter case, a little protection goes a long way. > > I know some people talk a lot about using web services to keep the > > proprietary data behind a secure server, but there is a large number of > > Ah yes, that would be me;-). Except that I don't limit my advice to > proprietary DATA -- it also applies to CODE worth keeping secret. Code is data, data is code. :) I meant it to refer to all information stored that way. > > applications where this is not practical - eg. image/audio processing, > > computer games, artificial intelligence, or several other applications > > with heavy real-time or cpu-intensive requirements, or embedded systems > > that don't have web access. > > Fewer and fewer systems "intrinsically lack" net access. For example, > good (costly) computer games more and more need net access to be played > in the best way (multiplayer etc). Sure, but there's still many, many programs that don't fit that criteria. Nor are people generally happy about being compelled to use online services to 'activate' their games. > "CPU intensive" is a weird reason to want to avoid keeping in a well > protected environment any code that's really worth money -- if it IS > worth that much you're no doubt charging enough for it to afford > supplying the CPU power to your customers (whatever your business model, > say pay-per-use or subscription levels with different maxima, etc etc). Maybe I wasn't making myself clear - I just meant that you can't be doing round-trips to a web server for per-pixel calculations. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
Ben Sizer <[EMAIL PROTECTED]> wrote: > bruno at modulix wrote: > > Let's rephrase it: > > "do you really think that native code is harder *enough* to > > reverse-engineer ?" > > I don't know. In terms of copy protection, popular off-the-shelf > software is going to get cracked whether it's written in Python or x86 > ASM, that much is true. But in terms of perhaps protecting innovative > algorithms from competitors, or something similar, compilation into > native code does a great job of hiding your work. Not a perfect job, > but a good enough job. If they're truly worth protecting, they're worth reverse engineering. Remember, the competition includes excellent programmers working in countries where $10 an hour's salary is luxury and IP law enforcements non-existent, so the cost to reveng is not as high as you might think. > I know some people talk a lot about using web services to keep the > proprietary data behind a secure server, but there is a large number of Ah yes, that would be me;-). Except that I don't limit my advice to proprietary DATA -- it also applies to CODE worth keeping secret. > applications where this is not practical - eg. image/audio processing, > computer games, artificial intelligence, or several other applications > with heavy real-time or cpu-intensive requirements, or embedded systems > that don't have web access. Fewer and fewer systems "intrinsically lack" net access. For example, good (costly) computer games more and more need net access to be played in the best way (multiplayer etc). "CPU intensive" is a weird reason to want to avoid keeping in a well protected environment any code that's really worth money -- if it IS worth that much you're no doubt charging enough for it to afford supplying the CPU power to your customers (whatever your business model, say pay-per-use or subscription levels with different maxima, etc etc). > > Perhaps the inclusion of ctypes will make it more practical to migrate > any sensitive code into native code libraries. Naah, ctypes shines when you access *pre-existing* dynamic libraries; if you're building those libraries yourself, it makes more sense to make them immediately usable from Python, e.g. via Pyrex, or SWIG, or SIP, or the C API, etc, etc. And if your secrets are truly valuable, none of those will really help keep them safe. If your secrets are worth diddlysquat, and the only reason to "protect" them is (e.g.) to keep some PHB happy (relying on the fact that he or she has no clue as to reality anyway), then go ahead -- use a Caesar cypher (as a just-arrested Mafia "capo di tutti i capi" appears to have done -- Italian police easily broke it, enabling it to arrest several other mafiosi!), or native code, or any other ineffectual approach. But if your wallet (or jailtime;-) is really on the line, do realize that they ARE ineffectual. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
bruno at modulix wrote: > Let's rephrase it: > "do you really think that native code is harder *enough* to > reverse-engineer ?" I don't know. In terms of copy protection, popular off-the-shelf software is going to get cracked whether it's written in Python or x86 ASM, that much is true. But in terms of perhaps protecting innovative algorithms from competitors, or something similar, compilation into native code does a great job of hiding your work. Not a perfect job, but a good enough job. I know some people talk a lot about using web services to keep the proprietary data behind a secure server, but there is a large number of applications where this is not practical - eg. image/audio processing, computer games, artificial intelligence, or several other applications with heavy real-time or cpu-intensive requirements, or embedded systems that don't have web access. Perhaps the inclusion of ctypes will make it more practical to migrate any sensitive code into native code libraries. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
Ben Sizer wrote:
> bruno at modulix wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>>>I suppose another idea is to rewrite entire Python app in C if compiled
>>>C code
>>>is harder to decompile.
>>
>>Do you really think "native" code is harder to reverse-engineer than
>>Python's byte-code ?
>
>
> Yes, until there's a native code equivalent of "import dis" that
> telepathically contacts the original programmer to obtain variable
> names that aren't in the executable.
Lol !-)
Ok, granted. Let's rephrase it:
"do you really think that native code is harder *enough* to
reverse-engineer ?"
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
bruno at modulix wrote: > [EMAIL PROTECTED] wrote: > > I suppose another idea is to rewrite entire Python app in C if compiled > > C code > > is harder to decompile. > > Do you really think "native" code is harder to reverse-engineer than > Python's byte-code ? Yes, until there's a native code equivalent of "import dis" that telepathically contacts the original programmer to obtain variable names that aren't in the executable. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
>>I'm afraid that the only *proven* way to protect code from >>reverse-engineering is to not distribute it *at all*. ain't that the truth. A hex editor would stop the "PyRun_SimpleString(secret_code)" Even if you encrypt your string they have to run at some point. A couple clicks in decent disassembler like softice when the program is running, and the program will have un-encrypted it for you. And besides, when you introduce drm (copy protection) into a program, you you take a chance on introducing bugs. There's nothing worse than losing legitimate customers over copy protection. Clean, Stable, Working programs sell better. The people that steal are going to steal it. So why not make people want to give you money for the good job you did. Not some buggy crap of a program that's too worried you might steal something. -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
Richard Brodie wrote: >> Do they ask the same thing for Java or .NET apps ?-) > > If you Google for "bytecode obfuscation", you'll find a large number > of products already exist for Java and .Net and if you google for "python obfuscator", you'll find tools for python. including tools that use "psychologically inspired techniques to produce extra confusion in human readers" (probably by inserting small snippets of Perl here and there...). -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
"bruno at modulix" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Do they ask the same thing for Java or .NET apps ?-) If you Google for "bytecode obfuscation", you'll find a large number of products already exist for Java and .Net -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
[EMAIL PROTECTED] wrote:
> How can a proprietary software developer protect their Python code?
> People often ask me about obfuscating Python bytecode. They don't want
> people to easily decompile their proprietary Python app.
Do they ask the same thing for Java or .NET apps ?-)
> I suppose another idea is to rewrite entire Python app in C if compiled
> C code
> is harder to decompile.
Do you really think "native" code is harder to reverse-engineer than
Python's byte-code ?
> Any ideas?
I'm afraid that the only *proven* way to protect code from
reverse-engineering is to not distribute it *at all*.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
> >> char secret_code[] = "print 'moshe'";
> >>
> >> int main()
> >> {
> >> return PyRun_SimpleString(secret_code);
> >> }
> >>
> >> and you need to link with python24.lib or whatever the object file is
> >> for your platform.
> >
> > Are you sure? On a linux platform I tried linking with libpython2.4.so
> > (I assume this is the correct object file) but it segfaults in
> > PyImport_GetModuleDict( ).
>
> I still don't understand why you think that embedding the *source code* in a
> variable
> named "secret" will do a better job than just putting the byte code in some
> non-obvious
> packaging, but if you insist on embedding the code, reading the
> documentation might
> help:
>
> http://docs.python.org/ext/embedding.html
> "At the very least, you have to call the function Py_Initialize()"
>
> http://docs.python.org/ext/high-level-embedding.html
> (minimal PyRun_SimpleString example)
Well, I was not the original poster in this thread I just picked up
the idea of executing python code that is assigned to a string from
within C and tried to do it with no particular goal, that's all. And
thanks a lot for the links, the docs are pretty clear, I should have
checked them before
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
"Daniel Nogradi" wrote:
>> char secret_code[] = "print 'moshe'";
>>
>> int main()
>> {
>> return PyRun_SimpleString(secret_code);
>> }
>>
>> and you need to link with python24.lib or whatever the object file is
>> for your platform.
>
> Are you sure? On a linux platform I tried linking with libpython2.4.so
> (I assume this is the correct object file) but it segfaults in
> PyImport_GetModuleDict( ).
I still don't understand why you think that embedding the *source code* in a
variable
named "secret" will do a better job than just putting the byte code in some
non-obvious
packaging, but if you insist on embedding the code, reading the documentation
might
help:
http://docs.python.org/ext/embedding.html
"At the very least, you have to call the function Py_Initialize()"
http://docs.python.org/ext/high-level-embedding.html
(minimal PyRun_SimpleString example)
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
> #include
>
> char secret_code[] = "print 'moshe'";
>
> int main()
> {
> return PyRun_SimpleString(secret_code);
> }
>
> and you need to link with python24.lib or whatever the object file is
> for your platform.
Are you sure? On a linux platform I tried linking with libpython2.4.so
(I assume this is the correct object file) but it segfaults in
PyImport_GetModuleDict( ).
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
okay, i got the name wrong. i wasn't trying to provide production-level
code, just a snippet. the function you want is
PyRun_SimpleString( const char *command)
#include
char secret_code[] = "print 'moshe'";
int main()
{
return PyRun_SimpleString(secret_code);
}
and you need to link with python24.lib or whatever the object file is
for your platform.
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
> #include
>
> char code[] = "print 'hello moshe'";
>
> void main(...)
> {
> Py_ExecString(code);
> }
I don't get this, with python 2.4 there is no function called
Py_ExecString in any of the header files. I found something that might
do the job PyRun_SimpleString( ) in pythonrun.h, but couldn't get it
to work either. So what is really the way to execute python code in a
string from a C program?
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
gangesmaster <[EMAIL PROTECTED]> wrote: ... > but anyway, it's stupid. why be a dick? those who *really* want to get > to the source will be able to, no matter what you use. after all, the > code is executing on their CPU, and if the CPU can execute it, so > can really enthused men. and those who don't want to use your product, > don't care anyway if you provide the source or not. so share. Alternatively, if you have secrets that are REALLY worth protecting, keep a tiny part of your app, embedding all worthwhile secrets, on YOUR well-secured server -- expose it as a webservice, or whatever, so the "fat client" (most of the app) can get at it. This truly gives you complete control: you don't care any more if anybody decompiles the part you distribute (which may be 90% or 99% of the app), indeed you can publish the webservice's specs or some API to encourage more and more people to write to it, and make your money by whatever business model you prefer (subscription, one-off sale, pay-per-use, your choice!). If you keep your client thin rather than fat, the advantages increase (your app can be used much more widely, etc), but you may need substantial amounts of servers and other resources to support widespread use. When I started proposing this approach, years and years ago, the fact that your app can work only when connected to the net might be considered a real problem for many cases: but today, connectivity is SO pervasive, that all sort of apps require such connectivity anyway -- e.g, look at Google Earth for a "fat client", Google Maps for a "thin" one accessing a subset of roughly the same data but running (the client side) inside a browser (with more limited functionality, to be sure). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
[EMAIL PROTECTED] wrote: > How can a proprietary software developer protect their Python code? > People often ask me about obfuscating Python bytecode. They don't want > people to easily decompile their proprietary Python app. > > I suppose another idea is to rewrite entire Python app in C if compiled > C code > is harder to decompile. > > Any ideas? Shuffle opcode values in random order, recompile Python, recompile stdlib, recompile py2exe (or whatever you use for bundling). It will keep attacker busy for several hours -- http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
well, you can do something silly: create a c file into which you embed
your code, ie.,
#include
char code[] = "print 'hello moshe'";
void main(...)
{
Py_ExecString(code);
}
then you can compile the C file into an object file, and use regular
obfuscators/anti-debuggers. of course people who really want to get the
source will be able to do so, but it will take more time. and isn't
that
the big idea of using obfuscation?
but anyway, it's stupid. why be a dick? those who *really* want to get
to the source will be able to, no matter what you use. after all, the
code is executing on their CPU, and if the CPU can execute it, so
can really enthused men. and those who don't want to use your product,
don't care anyway if you provide the source or not. so share.
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?)
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > How can a proprietary software developer protect their Python code? > People often ask me about obfuscating Python bytecode. They don't want > people to easily decompile their proprietary Python app. > > I suppose another idea is to rewrite entire Python app in C if compiled > C code > is harder to decompile. > > Any ideas? Go to Google's newsgroup archives for c.l.p (accessible via google.com) and search for some of the numerous past threads on this issue, which give several ideas and viewpoints. There may or may not also be something in the Python FAQ or Wiki at python.com. -- http://mail.python.org/mailman/listinfo/python-list
How protect proprietary Python code? (bytecode obfuscation?, what better?)
How can a proprietary software developer protect their Python code? People often ask me about obfuscating Python bytecode. They don't want people to easily decompile their proprietary Python app. I suppose another idea is to rewrite entire Python app in C if compiled C code is harder to decompile. Any ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
On Sun, 2005-02-06 at 08:19, Philippe Fremy wrote: > Adam DePrince wrote: > > No amount of obfuscation is going to help you. > > Theorically, that's true. Anything obfuscated can be broken, just like > the non obfuscated version. However it takes more skills and time to > break it. And that's the point. By raising the barrier for breaking a > product, you just eliminate a lot of potential crackers. > > > The worst case if you depend on obscurity: The bad guys are rounding > > off your pennies as you read this. > > That's the worst case, we all know that. A good case is to rely on open > spec and standard. However, obscurity can help if added on top of that. > > I remember an article of Fyodor explaining that if you run your internal > apache server on port 1234 (for an enterprise) with all the normal > security turned on, you avoid 80% of the common cracker. You should not > rely on the port number for security but changing it improves it. Okay, so only 20% of the script kiddies are filling the edges of your coins. It would seem that the article you quote is addressing the computer equivalent of a burglar. There is nothing personal between a burglar and a home owner (from the formers perspective at least.) Any home will do, and their victim is chosen from a large pool of equally uninteresting targets on the basis of their vulnerability. Those 80% don't notice your port 1234 because it serves no purpose. They aren't looking to break into you specifically, they are looking to break in anywhere, and the act of changing your port, much like attaching a chain to your wallet, makes you not worth the effort. There are two problems with your analogy. First, you are forgetting the economics of the situation. The low value of cracking yet another web server over shadows only the minuscule cost of port scanning the potential mark. The second problem with your analogy lies in the very nature of the problem you are trying to solve. Decompiling and securing your website are two different beasts, so much that it is not possible to draw conclusions about one from experiences with the other. The former is simply a matter of reading the code and emulating your cpu/virtual machine/etc by hand with a paper and pencil. Time consuming and tedious, but quite certain in its outcome. The barrier to decompiling this code has to be raised above the benefit you will get from decompiling it. If the server that this code to works correctly and depends on no magic within the client to protect itself from rounded pennies, then you are fine even if the code is reverse engineered, for the problem becomes one of the correctness of the implementation of the server code in the face of a hostile client. Doing this will foil your hacker by eliminating the benefit of reverse engineering. If the server is not robust, then the payoff becomes all of your rounded pennies. Even by the decedent wage standards of American programmers, the payoff greatly exceeds the labor cost of learning how your API works from the byte code. Remember, anything a computer can understand is a language that a human can learn too (there is a reason why computer science also goes by the name computational linguistics.) Obfuscate your code to the end of the world and all you have done is changed the language in which the programmer will learn your algorithm. Big deal, instead of turning it into python, I print up the symbolic representation of the python byte code, assembly, vhdl or whatever it might be. Low level languages are not that hard to read. Remember, if it can run on a computer, it can run on pencil and paper. Just look at the trouble DRM has ... they have to go so far as to introduce "trusted hardware", aka a machine that won't let you dump the machine code to your printer. Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
Adam DePrince wrote: No amount of obfuscation is going to help you. Theorically, that's true. Anything obfuscated can be broken, just like the non obfuscated version. However it takes more skills and time to break it. And that's the point. By raising the barrier for breaking a product, you just eliminate a lot of potential crackers. The worst case if you depend on obscurity: The bad guys are rounding off your pennies as you read this. That's the worst case, we all know that. A good case is to rely on open spec and standard. However, obscurity can help if added on top of that. I remember an article of Fyodor explaining that if you run your internal apache server on port 1234 (for an enterprise) with all the normal security turned on, you avoid 80% of the common cracker. You should not rely on the port number for security but changing it improves it. Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
snacktime <[EMAIL PROTECTED]> wrote: ... > How difficult is it to turn python bytecode into it's original source? It's pretty easy, not really the original source (you lose comments etc) but close enough to read and understand. > Is it that much different than java (this is what they will probably > compare it to) ? It's not very different from Java, or for that matter from C: Python's bytecode is a bit higher-level than Java's, which is a bit higher level than typical machine code, but not enough to make a difference if there is good illicit profit to be made in disassembling and studying it. > Also, I'm curious how much demand their is for this application in the > Python world. The application replaces online credit card There is as much _wishing_ for magic bullets to slay all monsters, and magic wands to cure all ills, in the Python world as in others, and generally just about the same recognition that the magic bullets and wands are not technically achievable. You can arrange things so that somebody wishing to study and reproduce your code will spend 10 hours instead of 5, maybe (with effort) can go all the way up to making them spend 20 hours -- but if reproducing that code is worth to them a few thousand bucks, you're toast anyway. Whatever code you let out of your control, it WILL get cracked if there's a profit in cracking it -- and sometimes even if there ain't (cfr, the cracks of hard-to-crack games abounding on warez sites). So, if you have any code whose secrecy is important, you just cannot allow it to get out of your control -- keep it on a solid and closely guarded server and allow access to it only via well-controlled web services or the like. For example: > processors(Verisign, Authorizenet) by providing a platform that > connects directly to the bank networks for credit card processing, and ...the code would have to connect (with non-secrecy-critical code) to a secure server which then does the secrecy-critical connection to the bank networks -- assuming the secrecy IS critical for that part. If you're currently distributing that ``secrecy critical'' code as JVM bytecodes or intel machine code, and there IS indeed a profit to be made in cracking it, rest assured that it IS cracked, somewhere. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
On Thu, 2005-02-03 at 16:58, Jarek Zgoda wrote: > snacktime napisał(a): > > > Everything except the libraries that actually connect to the > > bank networks would be open source, and those libraries aren't > > something that you would even want to touch anyways. > > This sounds suspicious to me. Really. Normal payment clearance programs > have open-spec API's. Dare I suggest that closed source is a plea for rounding fraud? No amount of obfuscation is going to help you. Just look at the battles between virii authors and anti-virus software firms. Even as early as the 80's, viruses were employing elaborate encryption schemes to "hide" from virus scanners; virus scanners in return emulated the cpu for the first couple thousand cycles in hopes of finishing the decryption and seeing the virus. Of course, virus authors responded with for(x=0;x<100;x++) and the halting problem inspired game of chicken raged on ... the difference with your situation is if somebody is using obscurity as a form of security, then it means that your system is reachable, and it is only a matter of money and time before the obscurity becomes not very obscure. My humble recommendation is to put your efforts into educating those you work with that if they secure their communication channel it won't matter if the protocol spec leaks to the world. Your adversary won't have an opportunity to talk to your service no matter how good their implementation of your protocol. The worst case if you depend on obscurity: The bad guys are rounding off your pennies as you read this. The worse case if you depend on encryption and open your spec: You get to publish your code, but might get competition. Just my $0.02. Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
snacktime wrote: Also, I'm curious how much demand their is for this application in the Python world. The application replaces online credit card processors(Verisign, Authorizenet) by providing a platform that connects directly to the bank networks for credit card processing, and also provides other features such as recurring billing, reporting, etc.. Everything except the libraries that actually connect to the bank networks would be open source, and those libraries aren't something that you would even want to touch anyways. Personally, I would avoid running any software that processed my users' credit cards that wasn't open source. Not to say I wouldn't use it, but it would have to come from a known-reliable source with their full backing to imply the security of their name. e.g. If it was a bytecode library downloadable directly from bankofamerica.com. The risk of devious programming is too high to bother. So I pay Verisign or Authorizenet one cent on the dollar. In exchange, my clients' identities aren't being stolen. Hope this help, Gabriel. -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
On Thu, 3 Feb 2005 17:28:50 -0500, Daniel Bickett <[EMAIL PROTECTED]> wrote: > snacktime wrote: > > How difficult is it to turn python bytecode into it's original source? > > Is it that much different than java (this is what they will probably > > compare it to) ? > > As far as I know, that depends on how much money you're willing to > pour into it ;) > > http://www.crazy-compilers.com/decompyle/ > > Other than that link, which I stumbled upon at some point (at > python-eggs), I'm decidedly uninformed on this subject. I just stumbled on Pyrex which seems to be exactly what I needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
snacktime wrote: > How difficult is it to turn python bytecode into it's original source? > Is it that much different than java (this is what they will probably > compare it to) ? As far as I know, that depends on how much money you're willing to pour into it ;) http://www.crazy-compilers.com/decompyle/ Other than that link, which I stumbled upon at some point (at python-eggs), I'm decidedly uninformed on this subject. -- Daniel Bickett dbickett at gmail.com http://heureusement.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
snacktime> How difficult is it to turn python bytecode into it's snacktime> original source? Not very. Google for "python decompyle". Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
> > > Everything except the libraries that actually connect to the > > bank networks would be open source, and those libraries aren't > > something that you would even want to touch anyways. > > This sounds suspicious to me. Really. Normal payment clearance programs > have open-spec API's. > I think you might be thinking of api's from companies like Verisign, which are online payment processors. Online payment processors in turn connect to direct processors such as Firstdata, Vital, Global Payment, etc.. Those direct processors do not have open-spec API's, at least none of them that I have worked with and I've certified with most of them at one point or another. -- http://mail.python.org/mailman/listinfo/python-list
Re: bytecode obfuscation
snacktime napisał(a): Everything except the libraries that actually connect to the bank networks would be open source, and those libraries aren't something that you would even want to touch anyways. This sounds suspicious to me. Really. Normal payment clearance programs have open-spec API's. -- Jarek Zgoda http://jpa.berlios.de/ | http://www.zgodowie.org/ -- http://mail.python.org/mailman/listinfo/python-list
bytecode obfuscation
I am attempting to put together and open source project, but some of the libraries cannot be open source due to non disclosure agreements. The non disclosures specifically specify that the implementation of their api's can only be distributed as object code. I might be able to get them to agree to bytecode, but probably only if I can obfuscate it in some way, or show that it is very difficult to turn the bytecode back into python source code. How difficult is it to turn python bytecode into it's original source? Is it that much different than java (this is what they will probably compare it to) ? Also, I'm curious how much demand their is for this application in the Python world. The application replaces online credit card processors(Verisign, Authorizenet) by providing a platform that connects directly to the bank networks for credit card processing, and also provides other features such as recurring billing, reporting, etc.. Everything except the libraries that actually connect to the bank networks would be open source, and those libraries aren't something that you would even want to touch anyways. -- http://mail.python.org/mailman/listinfo/python-list
