Nokia Mobilecodes

Here is their site. Google doesn’t seem to think they’re relevant when looking for “symbian 2d barcode, ” etc.

Creating new projects in Carbide

Creating a new project in Carbide C++ v1.3 entails a journey through several dialog boxes, one of which requests the name for the new project and a directory in which to put it. Carbide’s default location has a tendency to generate an error to the tune of “C:\Symbian\Carbide\Workspace is not a valid location”, even though the greyed-out default location shows, e.g., “C:\Symbian\Carbide\Workspace\MyNewProj”. I work around this by unchecking the “use default location” box and creating MyNewProj manually.

Microsoft Product Keys

Sometimes a Windows machine needs to be reinstalled. Theoretically, it shouldn’t be necessary, but sometimes that’s what’s gotta happen. And sometimes it can be hard to find all of the product key sleeves from the original installation media. Enter Magical Jelly Bean Keyfinder. Sounds ridiculous. Works.

Concatenating PDFs

Sounds easy, right? Ha!

This was the best page I found about it. It turns out there’s a pdftk that did the trick for me:


aptitude install pdftk
pdftk input1.pdf input2.pdf cat output input1and2.pdf


Drink Calculator

Planning a big event like a wedding or graduation party? Not sure how much alcohol to get for your guests. Evite has a handy drink calculator that at least gives an excuse if it turns out to be wrong.

Symbian: RSocket::Recv and HBufC8

A common way to do stream-based network communication in Symbian OS is with the RSocket class. The RSocket::Recv(TDes8 &aDesc, …) method “only completes when the full amount of requested data has been received (or the connection breaks). This means when the descriptor has been filled to its maximum length (not its current length).”

This is handy if an application receives messages of unknown length, but those messages include a header that includes the length. E.g., always receive 4 bytes of header which encode the amount of payload data. What seems like a sensible thing to do is dynamically allocate a buffer descriptor to hold exactly the expected payload size. This seems nice because then the OS worries about reassembling fragmented or long messages.

Unfortunately, note that the heap descriptor of choice, HBufC8, when allocated with HBufC8::NewL(TInt aMaxLength), may not be the expected size: “Note that the resulting heap cell size and, therefore, the resulting maximum length of the descriptor may be larger than requested.” This is a problem, because it causes RSocket::Recv() to hang waiting for more data than the remote end has sent.

I’m aware of three work-arounds, and zero elegant solutions:

• RSocket::RecvOneOrMore and manage buffers ourselves (more work: yuck).
• Allocate a C-style array and don’t use Symbian descriptors. This page talks about that solution.
• Cast the const pointer available for an HBufC8 and create a Tptr8 manually, assigning its max size to be precisely the message size. This page talks about that solution.

Currently I’m using the cast-away-the-const solution. Note that the HBufC8’s length will not be modified, so it must be set manually:

HBufC8 *iBuffer;
TPtr8 iBufferPtr;
...
iBufferPtr.SetLength(payloadSize); // without this iBuffer's length remains 0
iBufferPtr.Set((TUint8*)iBuffer->Des().Ptr(), 0, payloadSize);

My understanding is that SetLength() sets the current length of iBuffer. Set() sets the current length and maxlength of the TPtr8 object. Thus, RSocket sees the current length of 0 and max length of payloadSize, and behaves as expected. Code processing the iBuffer in some class’s RunL() will see the length that was set with SetLength(), but since RSocket is no longer operating with a mistaken notion of the desired amount of data to read, RunL() will only be called when the right amount of data has arrived.

It’s too late and I’m too tired to make this more concise. Forgive me.

UPDATE: It seems that an RBuf8 will solve this problem elegantly, but I haven’t had time to try it yet.

Parallels Reverse Transporter (Virtual to Physical)

Parallels for Max OS X allows me to run Windows XP in a virtual machine. Boot Camp allows native installation of Windows XP on Intel Macs. Parallels Transporter enables a Boot Camp-based native installation of Windows XP to run in a virtual machine while OS X is running, while simultaneously allowing the system to reboot and run Windows XP natively for extra graphics, performance, etc. Unfortunately, it’s designed assuming the native install of Windows XP was there first. In my case, I have a Windows XP virtual machine, and I would like the option to also boot it natively using Boot Camp. My best Google skills turned up this Virtual to Physical (Boot Camp) Guide, which is sufficiently involved that I haven’t tried it yet, but I will. Regardless, this virtual-to-physical transition is clearly something people want, and it’s only a matter of time.

Symbian OS V9.1+ C++ Cryptography APIs available!

I have been waiting forever for this!

My first objective was to generate an RSA keypair, generate some random data, generate a signature over that data, and then verify that the signature is correct. This worked, although there is some fine print in the descriptions of classes CRSAPKCS1v15Signer and CRSAPKCS1v15Verifier:

CRSAPKCS1v15Signer: This class creates RSA signatures following the RSA PKCS#1 v1.5 standard (with the one caveat noted below) and using PKCS#1 v1.5 signature padding. The only exception is that the SignL() function simply performs a ‘raw’ PKCS#1 v1.5 sign operation on whatever it is given. It does not hash or in any way manipulate the input data before signing.

CRSAPKCS1v15Verifier: This class verifies RSA signatures given a message and its supposed signature. It follows the RSA PKCS#1 v1.5 with PKCS#1 v1.5 padding specification with the following exception: the VerifyL() function does not hash or in any way manipulate the input data before checking.

Uh oh… complexity. The signature I generated and verified is not fully compliant with the relevant specifications. In particular, the widely used PKCS1 v1.5 padding isn’t implemented fully. Thus, when I went to verify a signature produced by an outside application, the verification failed. I couldn’t find any documentation that expressed precisely what was omitted from the Symbian implementation, so I had to do some detective work.

The signed data I am using is the output of a TPM_Quote operation performed by a Broadcom v1.2 TPM. Thus, I will restrict my discussion regarding the Symbian CRSAPKCS1v15* classes to verifying signatures. CRSAPKCS1v15Verifier::VerifyL is the function that refused to return ETrue. There is also CRSAPKCS1v15Verifier::InverseSignLC(), which returns the output of the RSA decrypt operation. Sounds good, since I’m trying to dissect the padding manipulation. The inverse signature for my test data was consistently (leading zeros are stripped):
3021300906052b0e03021a05000414d4bfa90ce1f23417b7d046911d6c35c6881f8282

It turns out the SHA-1 hash of my test data is d4bfa90ce1f23417b7d046911d6c35c6881f8282, leaving a strange header of 3021300906052b0e03021a05000414. I then turned to the trusty XySSL source code to look for what operations are performed between the RSA decrypt and the actual return of whether a verification was successful. The function of interest is rsa_pkcs1_verify(). When I ran my test data through that function, and dumped the data just the RSA decrypt, it looked like this: 0001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a05000414d4bfa90ce1f23417b7d046911d6c35c6881f8282. This is actually padded out to the appropriate width for the RSA key, but the interesting bytes at the end match the data the Symbian function was returning. The strange header is defined in the XySSL rsa.h:
#define ASN1_HASH_SHA1 \
"\x30\x21\x30\x09\x06\x05\x2B\x0E\x03" \
"\x02\x1A\x05\x00\x04\x14"

The Symbian Crypto APIs do include a CPaddingPKCS1Signature class, but after some testing its purpose appears to be soley the management of the leading 0xffs on the key-width padded signature. Thus, it looks like the Symbian CRSAPKCS1v15Verifier class actually makes use of the CPaddingPKCS1Signature internally to strip off the 0xff-based padding.

I haven’t yet taken the time to dig into the specs and figure out exactly what the purpose of ASN1_HASH_SHA1 is meant to be. For now, I’ve included it in my code as a literal and used
CRSAPKCS1v15Verifier::InverseSignLC. I then prepend ASN1_HASH_SHA1 to the output of the SHA-1 hash of the signed data, and compare to the output of InverseSignLC.

FYI, Symbian enables definition of binary literals by escaping octets with \x. For example:
_LIT8(KASN1_HASH_SHA1, "\x30\x21\x30\x09\x06\x05\x2B\x0E\x03\x02\x1A\x05\x00\x04\x14");

Also FYI, use of of the RInteger class can cause memory leaks. RInteger is unique in that its NewL() method does not return a pointer. It is important to call the Close() method on an RInteger.

UPDATE: Getting to the crypto api documentation from anything but the original installer has proven to be beyond me. It turns out, on my system at least, that the crypto api docs live in c:\Symbian\9.1\S60_3rd_MR\documentation\CryptographyLibraries.chm. In Windows, one can just paste that into Start -> Open. In Linux, ‘gnochm’ will open and display that file successfully.

Symbian Signed Debacle

I was really hoping to implement a simple application that does a little crypto exclusively in Python for my Nokia E51 (Symbian OS v9, Nokia Series 60 (S60) 3rd Edition), but Python for S60 doesn’t currently expose public key cryptography. I’ve decided to fall-back to Symbian C++, but all applications for S60 3rd Edition must be signed. It turns out they can be signed with a self-signed certificate, if the capabilities they require are minimal.

I used Carbide C++ v1.3 and created a new Symbian C++ Project. It complained bitterly that the default directory (a child of the active workspace) was not acceptable, and I have no idea why. I chose my own directory outside that path.

The application built and executed successfully on the emulator. I then re-built it for the phone, and tried to install the resulting SIS file. I then received the error message “Certificate error. Contact the application supplier.“. This page explains a lot about error messages, and is quite helpful. It turns out a signed application comes in a SISX file. When I tried to install that one it worked as expected.

My fingers are crossed that my development plans won’t require any capabilities that I’ll have to pay money to get. I must say, that’s an awfully high barrier to development.

SIS and Python for Series 60 (S60)

Make a SIS file from your Python app with Ensymble.