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
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 writte
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 te
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, u
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 equ
>>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 disa
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
"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:
[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 anot
> >> 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 libpy
"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 li
> #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
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 py
> #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 could
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 wh
[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 com
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
<[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 r
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
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 th
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
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 pro
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.
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 ot
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 depen
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/de
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
>
> > 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
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.
--
J
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 t
30 matches
Mail list logo
