headers
Spencer G. | 1 Apr 2011 01:39
Picon

Exported module missing symbols

I have what's called a Blizzard library which handles reading videos
by using FFmpeg. It's general use so a it can handle a huge variety of
formats. I was able to make the C code for the library, compile it as
libblizzard, wrap its header file using Cython, and make a python
BlizzardReader class using that library (also programmed in Cython).
That compiled just find and it created a blizzard.so file as it
should.

I made a test main.py which simply imports the blizzard library and
creates one BlizzardReader. But, when I ran it it gave me the
following error:

Traceback (most recent call last):
  File "main.py", line 2, in <module>
    import blizzard
ImportError: /home/spencer/blizzard_python/blizzard.so: undefined
symbol: blizzard_destroy

Here is the blizzard file:

cimport blizzard

cdef class BlizzardReader:
	"""
	An object responisble for reading a video file, grabbing frames from
it, and then destroying
	itself properly when done.
	"""

	cdef blizzard.BlizzardReader* reader
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lisandro Dalcin | 1 Apr 2011 02:08
Picon
Gravatar

Re: Exported module missing symbols

On 31 March 2011 20:39, Spencer G. <sgraffe <at> gmail.com> wrote:
> I have what's called a Blizzard library which handles reading videos
> by using FFmpeg. It's general use so a it can handle a huge variety of
> formats. I was able to make the C code for the library, compile it as
> libblizzard, wrap its header file using Cython, and make a python
> BlizzardReader class using that library (also programmed in Cython).
> That compiled just find and it created a blizzard.so file as it
> should.
>
> I made a test main.py which simply imports the blizzard library and
> creates one BlizzardReader. But, when I ran it it gave me the
> following error:
>
>
>
> Traceback (most recent call last):
>  File "main.py", line 2, in <module>
>    import blizzard
> ImportError: /home/spencer/blizzard_python/blizzard.so: undefined
> symbol: blizzard_destroy
>
>
>
> Here is the blizzard file:
>
>
>
> cimport blizzard
>
> cdef class BlizzardReader:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Behnel | 1 Apr 2011 02:18
Picon
Favicon

Re: Cython Reverse Engineering?

Shalom Rav, 01.04.2011 00:36:
> Is it easy / much easier to reverse engineer compiled cython code,
> than say to c++ code?

Never tried it, but I would expect that both are about equally tricky for a 
human. Potentially, reverse engineering Cython code could be easier to 
reverse engineer automatically than manually written code as it obviously 
follows generation patterns.

But I think it needs to be tried to get a justified answer.

> Is there anything that can be done to make cython code more
> 'resistable' to reverse engineering?

If you are thinking of code obfuscation, this has never been a goal of the 
Cython project (and it never will be).

Stefan
Permalink | Reply | 2 comments |
headers
Shalom Rav | 1 Apr 2011 02:31
Picon

Re: Cython Reverse Engineering?

Stefan,

>
> If you are thinking of code obfuscation, this has never been a goal of the
> Cython project (and it never will be).
>

This makes perfect sense. The question is, is there anything that can
be done to make the code 'more complicated' for reverse engineering?
Shall comments be removed? other tactics?

On Mar 31, 8:18 pm, Stefan Behnel <stefan... <at> behnel.de> wrote:
> Shalom Rav, 01.04.2011 00:36:
>
> > Is it easy / much easier to reverse engineer compiled cython code,
> > than say to c++ code?
>
> Never tried it, but I would expect that both are about equally tricky for a
> human. Potentially, reverse engineering Cython code could be easier to
> reverse engineer automatically than manually written code as it obviously
> follows generation patterns.
>
> But I think it needs to be tried to get a justified answer.
>
> > Is there anything that can be done to make cython code more
> > 'resistable' to reverse engineering?
>
> If you are thinking of code obfuscation, this has never been a goal of the
> Cython project (and it never will be).
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lisandro Dalcin | 1 Apr 2011 03:16
Picon
Gravatar

Re: Re: Cython Reverse Engineering?

On 31 March 2011 21:31, Shalom Rav <csharpplusproject <at> gmail.com> wrote:
> Stefan,
>
>>
>> If you are thinking of code obfuscation, this has never been a goal of the
>> Cython project (and it never will be).
>>
>
> This makes perfect sense. The question is, is there anything that can
> be done to make the code 'more complicated' for reverse engineering?
> Shall comments be removed? other tactics?
>

Optimizing compilers will add extra fuzziness, not need at all to
remove code, etc... Take into account that Cython code calls the
Python C/API, this API do have public symbols with very readable
names. If you manage to run a code obfuscator in core Python sources
and build a custom binary (no idea how this could work, the generator
should also output a header plenty of #defines for you to #include),
then I think the whole stack will be harder to reverse-eng...

> On Mar 31, 8:18 pm, Stefan Behnel <stefan... <at> behnel.de> wrote:
>> Shalom Rav, 01.04.2011 00:36:
>>
>> > Is it easy / much easier to reverse engineer compiled cython code,
>> > than say to c++ code?
>>
>> Never tried it, but I would expect that both are about equally tricky for a
>> human. Potentially, reverse engineering Cython code could be easier to
>> reverse engineer automatically than manually written code as it obviously
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fabrizio Milo aka misto | 1 Apr 2011 12:32
Picon
Gravatar

Re: Re: Wrapping template function

Any update on function templating ?

I like the Idea of

with template[ T, U, V]:
     U function( T, V)

Any entry point to start thinking for a possible patch?

Fabrizio
--------------------------
Luck favors the prepared mind. (Pasteur)
Permalink | Reply | 0 comments |
headers
Eric Frederich | 1 Apr 2011 18:10
Picon

using constants in prototypes

I have a header file which defined a constant integer then uses that
constant in function prototypes.
How to I handle this?
It works fine when I put 129 instead of BAR + 1, but I don't want to
have to do that.
There are a handful of constants and hundreds of prototypes that use them.

What should the corresponding pxd file look like for this foo.h?
Thanks,
~Eric

=== foo.h ===

#define BAR 128

int spam(const char eggs[BAR + 1]);

=== foo.pxd ===

cdef extern from "foo.h":

    ???
    ???
Permalink | Reply | 2 comments |
headers
Lisandro Dalcin | 1 Apr 2011 18:33
Picon
Gravatar

Re: using constants in prototypes

On 1 April 2011 13:10, Eric Frederich <eric.frederich <at> gmail.com> wrote:
> I have a header file which defined a constant integer then uses that
> constant in function prototypes.
> How to I handle this?
> It works fine when I put 129 instead of BAR + 1, but I don't want to
> have to do that.
> There are a handful of constants and hundreds of prototypes that use them.
>
> What should the corresponding pxd file look like for this foo.h?
> Thanks,
> ~Eric
>
> === foo.h ===
>
> #define BAR 128
>
> int spam(const char eggs[BAR + 1]);
>
> === foo.pxd ===
>
> cdef extern from "foo.h":
>
>    ???
>    ???
>

cdef extern from "foo.h":
    enum: BAR
    int spam(char eggs[])
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Frederich | 1 Apr 2011 19:19
Picon

Re: using constants in prototypes

Ahh.... that was easy.

What would I do if I needed to use a character array in a .pyx file though?
Is the solution to just use
    cdef char* xyx
instead of
    cdef char xyz[BAR]

On Fri, Apr 1, 2011 at 12:33 PM, Lisandro Dalcin <dalcinl <at> gmail.com> wrote:
> On 1 April 2011 13:10, Eric Frederich <eric.frederich <at> gmail.com> wrote:
>> I have a header file which defined a constant integer then uses that
>> constant in function prototypes.
>> How to I handle this?
>> It works fine when I put 129 instead of BAR + 1, but I don't want to
>> have to do that.
>> There are a handful of constants and hundreds of prototypes that use them.
>>
>> What should the corresponding pxd file look like for this foo.h?
>> Thanks,
>> ~Eric
>>
>> === foo.h ===
>>
>> #define BAR 128
>>
>> int spam(const char eggs[BAR + 1]);
>>
>> === foo.pxd ===
>>
>> cdef extern from "foo.h":
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maarten | 1 Apr 2011 19:29
Picon

Re: Calling c++ static method

Great that solved my issue, thanks a lot!

On Mar 30, 2:08 pm, Lisandro Dalcin <dalc... <at> gmail.com> wrote:
> On 29 March 2011 18:22, Maarten <m.da... <at> gmail.com> wrote:
>
>
>
> > Update: in the generated code the method call Create seems to be
> > assigned to a pointer. Why is that? I only called that method, and
> > didn't assign it to anything.
> > Here are the relevant parts from the generated code:
>
> > PyObject *__pyx_t_1 = NULL;
> > __pyx_t_1 = OpenZWave::Options::Create(std::string(__pyx_v_a),
> > std::string(__pyx_v_b), std::string(__pyx_v_c)); if (unlikely(!
> > __pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 23;
> > __pyx_clineno = __LINE__; goto __pyx_L1_error;}
>
> > On Mar 29, 11:44 am, Maarten <m.da... <at> gmail.com> wrote:
> >> Hi,
>
> >> I have some problems calling c++ static methods.
> >> I'm tying to call the Options::Create static method:
>
> >> namespace OpenZWave
> >> {
> >>         class Options
> >>         {
> >>         public:
> >>                 enum OptionType
(Continue reading)

Permalink | Reply | 0 comments |

Gmane