[y.a.k]

I'm quite new to 3rd edition platform. The question I have is: how do I install sis files with PyS60 modules that require some caps if the sis file was created before the Symbian Signed change.

As far as I understand it, before the change, one created his own developer certificate and it was enough for him to sign a sis file for his phone. Right now our only option is the Open Signed Online which, unless the UID is from a testrange, would send a signed sis file only to the owner of the UID.

For example, right now I'm trying to make the keypress module to work on my N73. On cyke64's web site I found the following file:
keypress102_unsigned_dev_certfree.sis

It won't install directly, the phone says something about invalid or no longer valid certificate. How do I install it then? The only option that I came with was to extract all the files and use ensymble with its simplesis command. This way I could specify a testrange UID. Of course it didn't install directly again because of caps problem. However, thanks to the testrange UID I was able to sign it usign Open Signed Online. This helped, but not fully. As soon as I try to call the simulate_key function, Python shuts down without any error (even in try...except).

Could someone explain me how do you do it?

-- ADDED --
I've tried making my key and cert using makekeys and then sign the sis using signsis but the phone still whine about missing caps.

[jethro.fn]

Originally Posted by y.a.k

I'm quite new to 3rd edition platform. The question I have is: how do I install sis files with PyS60 modules that require some caps if the sis file was created before the Symbian Signed change.

As far as I understand it, before the change, one created his own developer certificate and it was enough for him to sign a sis file for his phone. Right now our only option is the Open Signed Online which, unless the UID is from a testrange, would send a signed sis file only to the owner of the UID.

Yeah, you just hit the wall each of us has hit at some point. When Symbian discontinued the free developer certificates and introduced Open Signed Online, all old extension modules were left hanging. It was no longer possible for new PyS60 users to sign the modules for their own phones, due to the fact that Open Signed Online does not accept SIS files with arbitrary UIDs. And even those who had developer certificates are out of luck, as the certificates have now expired.

Slowly, module authors have moved to the test-range UIDs, but there are still plenty of modules that have not been updated.

Originally Posted by y.a.k

For example, right now I'm trying to make the keypress module to work on my N73. On cyke64's web site I found the following file:
keypress102_unsigned_dev_certfree.sis

It won't install directly, the phone says something about invalid or no longer valid certificate.

Those types of packages (with free, dev and/or cert in their names) were meant to be personally signed using the free developer certificate. Prior to signing they contain a dummy certificate (typically the Ensymble default self-signed certificate) which is not potent enough to persuade the phone to install the package.

Originally Posted by y.a.k

How do I install it then? The only option that I came with was to extract all the files and use ensymble with its simplesis command. This way I could specify a testrange UID. Of course it didn't install directly again because of caps problem. However, thanks to the testrange UID I was able to sign it usign Open Signed Online. This helped, but not fully. As soon as I try to call the simulate_key function, Python shuts down without any error (even in try...except).

Could someone explain me how do you do it?

If the extension module does not reference its own UID in the code, it is possible two modify the DLL header using the altere32 command of Ensymble. Capability bitmask can be tweaked as well.

There are four aspects ("roadblocks") that determine if a program can succesfully use a capability:

• Capabilities listed in the certificate: These capabilities determine if an application can be installed. The phone will check the header of each EXE and DLL (remember that PYDs are DLLs too) against the capabilities of the certificate. If the certificate does not have a capability that is declared in any EXE or DLL, the installation fails. Also, if the certificate has more capabilities listed than what is allowed for its type (self-signed vs. Symbian signed), the installation fails.
• Capability bitmask of EXEs: The capability bitmask in the header of EXE files determine if an application process is allowed to use a certain capability. If the application tries to use a feature protected by a capability that it has not declared in its header, access to that feature is prevented by the system.
• Capability bitmask of DLLs: In contrast to EXEs, the capability bitmask in DLLs will not grant any capabilities to the code in the DLL, or any other code for that matter. It is only used to determine which applications are allowed to load the DLL. An application is only alowed to load DLLs that have at least those capabilities that the application itself has. This prevents loading "untrusted" DLLs to applications with capabilities that could compromise system security.
• Actual usage in the program: When a program tries to use a feature that requires a specific capability, the system checks if the application process has that capability enabled. If not, a feature-specific error code is returned. In Python's case this may lead to abrupt program termination, if the interpreter has no special code to handle the situation and convert it to Python exception.

Originally Posted by y.a.k

-- ADDED --
I've tried making my key and cert using makekeys and then sign the sis using signsis but the phone still whine about missing caps.

Simulating keypresses requires the SwEvent capability, which is not available to applications that have a self-signed certificate. When you create a certificate and key with makekeys, it creates a self-signed certificate. That certificate is no better than the default one that comes with Ensymble. In fact it is worse, since makekeys generates certificates that expire in *COUGH* days, whereas the Ensymble default certificate is good for another 28 years (30 years originally, expires on Sep 25 18:21:04 2036 GMT).

[cyke64]

Originally Posted by jethro.fn

Yeah, you just hit the wall each of us has hit at some point. When Symbian discontinued the free developer certificates and introduced Open Signed Online, all old extension modules were left hanging. It was no longer possible for new PyS60 users to sign the modules for their own phones, due to the fact that Open Signed Online does not accept SIS files with arbitrary UIDs. And even those who had developer certificates are out of luck, as the certificates have now expired.

Not true if you get your last free dev cert during the end of last year when they have extended the duration to 3 (THREE) years instead of six months So my cert for my old device expired only in December 2010
So I sign always Python extension with MobileSigner (great app) in my devices
But for all new device I get after this politic change I have only online signing

Originally Posted by jethro.fn

Slowly, module authors have moved to the test-range UIDs, but there are still plenty of modules that have not been updated.

Yes but test range is dangerous (problem : give the same UID3 to different Python extension !)
We should take a convention with Python extension developers for avoiding UID clashes in the future.
Yes I think than no modules use test range actually
All my modules *should* to follow this convention ...

BR
Cyke64

[y.a.k]

I see. Someone should put up a website simmilar to Symbian Signed that would allow you to register an UID from the test range. With some proper "advertising", I don't think there would be a problem making people into actually using the site when they are releasing a module.

A nice and friendly database of all open software with ability to display a list of them.

Anyone?

[y.a.k]

I've unpacked the sis using sisinfo. Then did this:

> ensymble.py info32 _keypress.pyd

_keypress.pyd:
    UID1          0x10000079
    UID2          0x00000000
    UID3          0x00000000
    Secure ID     0x00000000
    Vendor ID     0x00000000
    Capabilities  0xff1b4 (ALL-TCB-CommDD-MultimediaDD-DRM-DiskAdmin-NetworkControl-AllFiles)

> ensymble.py altere32 --uid=0xe0001111 --secureid=0xe0001111 --inplace _keypress.pyd

> ensymble.py infoe32 _keypress.pyd

_keypress.pyd:
    UID1          0x10000079
    UID2          0x00000000
    UID3          0xe0001111
    Secure ID     0xe0001111
    Vendor ID     0x00000000
    Capabilities  0xff1b4 (ALL-TCB-CommDD-MultimediaDD-DRM-DiskAdmin-NetworkControl-AllFiles)

> ensymble.py simplesis --uid=0xe0001111 keypress keypress.sis
ensymble.py: warning: no package version given, using 1.0.0
ensymble.py: warning: no certificate given, using insecure built-in one

Of course there was some directory changing inbetween. Then I've signed it online. It still crashes Python when I do this:

>>> import keypress
>>> from key_codes import *
>>> keypress.simulate_key(EKey1, EKey1)

Is the module simply buggy or what? Just have to know if I did the testrange conversion right.

[jethro.fn]

Originally Posted by y.a.k

Is the module simply buggy or what? Just have to know if I did the testrange conversion right.

Have you added the SwEvent capability to your application (or to Script Shell and/or PED) as well? (Use the --caps option of the py2sis command of Ensymble.) Looks like the application crashes when it tries to use a capability-protected feature.

[croozeus]

Originally Posted by cyke64

Not true if you get your last free dev cert during the end of last year when they have extended the duration to 3 (THREE) years instead of six months So my cert for my old device expired only in December 2010

Yeah same is the case with me, we get 3 golden years of an exclusive dev cert

My 6 months dev cert has already expired

Best Regards,
Croozeus

[y.a.k]

Originally Posted by jethro.fn

Have you added the SwEvent capability to your application (or to Script Shell and/or PED) as well?

Right, silly me. Works now!

But I wonder. Was the PYD UID change really necessary? And is it normal that it had UID=0x00000000? Without the change (when I only repacked the sis using ensymble simplesis --uid=0xe0001111) it also installed and would probably also work (if I haven't forgot to sign Ped ). What do you think? Would there be any problem if I tried to install another extension module with its PYD having UID=0x00000000?

[jethro.fn]

Originally Posted by cyke64

Not true if you get your last free dev cert during the end of last year when they have extended the duration to 3 (THREE) years instead of six months So my cert for my old device expired only in December 2010

Wow. I have three certificates (Aug 2007, Nov 2007 and a more recent one which I cannot find just now). Each has expired in only six months...

Originally Posted by cyke64

Yes but test range is dangerous (problem : give the same UID3 to different Python extension !)
We should take a convention with Python extension developers for avoiding UID clashes in the future.

One possible solution is to let Ensymble choose the UID. It generates unique test-range UIDs automatically from the application name (not case-sensitive), when using the py2sis command. Make a dummy directory with one empty default.py file and use the --verbose option to see what UID Ensymble generates for it, for example:

• flashy: 0xe27db9f0
• hack: 0xe2732153
• keypress: 0xe6e6d76f
• sysagent: 0xe312c80d
• uitricks: 0xefa7eac9

And my favourite:

• test: 0xe87f7e0c

[jethro.fn]

Originally Posted by y.a.k

Right, silly me. Works now!

But I wonder. Was the PYD UID change really necessary? And is it normal that it had UID=0x00000000?

UID 0x00000000 is a special KNullUID in Symbian OS. I don't know what happens if you install it or several DLLs sharing the same UID.

[y.a.k]

Originally Posted by jethro.fn

One possible solution is to let Ensymble choose the UID. It generates unique test-range UIDs automatically from the application name (not case-sensitive), when using the py2sis command.

That's interesting. What's the algorithm? When could it possibly fail (generate same UIDs for different names)?

Output SIS file     Ped_2.30.1_beta_3rdEd_unsigned_testrange.sis
UID                 0xe9e58be1
Application name    Ped

Btw. You should add the code to exclude PythonShell test-range UID, if you haven't done so yet. And maybe a command to just generate UIDs based on a name.

[jethro.fn]

Originally Posted by y.a.k

That's interesting. What's the algorithm? When could it possibly fail (generate same UIDs for different names)?

...

Btw. You should add the code to exclude PythonShell test-range UID, if you haven't done so yet. And maybe a command to just generate UIDs based on a name.

Here's the relevant code from cmd_py2sis.py:

    if uid3 == None:
        # No UID given, auto-generate a test UID from application name.
        uid3 = (symbianutil.crc32ccitt(appname.lower()) &
                0x0fffffffL) | 0xe0000000L
        print ("%s: warning: no UID given, using auto-generated "
               "test UID 0x%08x" % (pgmname, uid3))

appname is what it says on the "Application name" line when using the --verbose option.

So, it takes a lower-case version of appname and calculates a common variant of 32-bit CRC out of it. The four topmost bits are set to "e" to place the UID in the test range, rest of the bits (28 of them) come from the CRC, so in theory a collision happens in 1/268,435,456 of cases. In reality, collisions are far more common than that because the CRC output is not ideally distributed. I think it is fine for this purpose, however.

For the same reason I think it is not likely to be able to create a name that has the same UID as the Script Shell. Of course there are algorithmic means for generating CRC-collisions, but most colliding strings are not suitable for use as application names.

EDIT: A command to generate UIDs, good idea!

[croozeus]

Originally Posted by jethro.fn

EDIT: A command to generate UIDs, good idea!

Jussi, Any Plans on it?

Best Regards,
Croozeus

[jethro.fn]

Originally Posted by croozeus

Jussi, Any Plans on it?

Not yet. Programming it is a simple job, but updating the documentation is always a chore...

In the meantime, you can get a UID generated by creating a SIS out of a dummy file appname.py. The suffix .py will not be a part of the name used for UID generation. You can get the same result by creating a SIS out of a directory appname, which only needs to contain a dummy default.py to keep Ensymble from printing an error.

[y.a.k]

Another idea. Ensymble could detect if the UID specified with --uid is a test-range one and if it is, it would calculate the CRC one based on the name. If they are different, it would print out a warning/info saying that the user should consider letting Ensymble handle the UID itself.

This way the fact that Ensymble can do this would easily get to new developers not knowing this already.