ImportError: Unknown magic number 62215

[glensc]

seems this old issue still not resolved:
wibiti/uncompyle2#23

➔ uncompyle6 zipfile.pyc 
Traceback (most recent call last):
  File "/usr/bin/uncompyle6", line 9, in <module>
    load_entry_point('uncompyle6==2.5.0', 'console_scripts', 'uncompyle6')()
  File "/usr/share/python2.7/site-packages/uncompyle6/bin/uncompile.py", line 160, in main_bin
  File "/usr/share/python2.7/site-packages/uncompyle6/main.py", line 119, in main
  File "/usr/share/python2.7/site-packages/uncompyle6/main.py", line 52, in uncompyle_file
  File "/usr/share/python2.7/site-packages/xdis/load.py", line 89, in load_module
ImportError: Unknown magic number 62215 in zipfile.pyc

to reproduce this, download dropbox linux client and unpack it:

• wget http://dl-web.dropbox.com/u/17/dropbox-lnx.x86_64-5.4.24.tar.gz
• tar xf dropbox-lnx.x86_64-5.4.24.tar.gz
• uncompyle6 .dropbox-dist/dropbox-lnx.x86_64-5.4.24/tornado-4.2-py2.7-linux-x86_64.egg/tornado/test/__init__.pyc

i just picked smallest .pyc file from the dist, but any file would do

[rocky]

The short is we need more information about that specific Magic number and what marshal format it uses. BTW that information now handled by project http://github.com/rocky/python-xdis not this one.

So let's review what's in that old issue.

wibiti:

That magic number is "newer" than the the most recent python 2.7.3 release.
Maybe it's from a pre-release version of 2.7.4. Or it could be from a custom python version.
You could try adding 62215 to the magic numbers in magics.py.

SharmaVimarsh:

After adding the magic number in magics.py file, now its giving me "ValueError: bad marshal data (unknown type code)"

wibiti

That error comes from the marshal module which is a standard python module.

Even though we are on 2.7.11 or 2.7.12, the same thing applies. Note that pycdc barfs on this as well.

[glensc]

the reproducer is present in bugreport (all needed for debugging is public content) and the .pyc files in question are not mine, do not know how ithey are produced. i can only guess it's from "custom build". the error is reproducible with any .pyc from the tarball.

[rocky]

In order for this to be a proper bug report that is actionable, I need:

1. A python interpreter that can execute this code. Let's start out with what python -V reports. Do you have that?
2. Information about what rules it uses for demarshalling. Whatever rules it is following, it doesn't fit into later Python 2.7's or Python 3.x releases.

When you have this feel free to reopen in the xdis repo.

[glensc]

Those Python files are used by dropbox client, there's no "bin/python" just "bin/dropbox" binary:

$ ldd .dropbox-dist/dropbox-lnx.x86_64-3.20.1/dropbox
        linux-vdso.so.1 (0x00007fffb61fe000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f750b7dd000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f750b5d9000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f750b3d6000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f750b0d1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f750ad2d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f750b9fa000)
$ LC_ALL=C ls -ld .dropbox-dist/dropbox-lnx.x86_64-3.20.1/dropbox
-rwxr-xr-x 1 glen glen 23697900 May  7 01:30 .dropbox-dist/dropbox-lnx.x86_64-3.20.1/dropbox*

[rocky]

xdis release 2.3.0 can now decode custom dropbox Python binaries with magic number 62215.

That's the magic now from an older release of dropbox. I don't imagine uncompyle6 will handle newer releases unless others deal with the decryption aspect needed dropbox's python bytecode.