Uncategorized


I’ve been playing around with SMS PDUs encodings and recently observed some curious things regarding the way that cellphones treat the text messages when they include special characters.First look at these two tables of the GSM alphabet:GSM7 Alphabet

GSM7 Alphabet (special)
The tables above show the GSM Alphabet using a 7-bit encoding which implies a maximum number of 160 characters per text message. However, sometimes this is a little bit more tricky and the count is not so straightforward:
If, for instance, you type a character from the second table, it needs to be escaped with the escape character 1) 0xB1, and it will take two characters instead of one. What happens if your text message contains 160 characters and one of them is a ‘]’?
Simple: You will get charged for two text messages because you’re exceeding the maximum length of a simple PDU.
Usually your cellphone won’t warn you about this and you will send it anyways without knowing the fact that this text message will cost twice than you think. The same happens with the ‘€’ symbol and some other not showing up in the table above.If you have a closer look at the tables, you might realize that the ‘é’ symbol appears but where are ‘á’,'í’,'ó’ and ‘ú’? The GSM alphabet was originally designed by France and they only use ‘é’ so if you want to use accents, there’s no way using this encoding.
I have tested some cellphones and they behave in two different ways:

  1. Removing those characters with accents (except ‘é’) and substituting them by the same character without accent.
  2. Using a 16-bit UNICODE encoding to allow sending every character (in this case, the maximum length of the textmessage is 70 characters).

In case 1, the only ’side-effect’ is that the recipient of the text message won’t get your accents and you can send up to 160 characters.
In case 2, your cellphone won’t warn you and you might send up to 160 characters thinking that it will take just one text message.However, again, you will be charged for up to 3 text messages without knowing it! The recipient will get a multi-part message showing all the characters you sent with no modification.
Here you can see the decoding of a PDU (using PDUSpy) of a text message sent with accents and encoded using UCS2:

  • PROTOCOL IDENTIFIER (0×00)
  • MESSAGE ENTITIES : SME-to-SME
  • PROTOCOL USED : Implicit / SC-specific
  • DATA CODING SCHEME (0×08)
  • AUTO-DELETION : OFF
  • COMPRESSION : OFF
  • MESSAGE CLASS : NONE
  • ALPHABET USED : 16bit UCS2

If the accents are removed from the original text message, the cellphone will automatically use the GSM7 alphabet and you will be allowed to send up to 160 characters in just one PDU (you will get charged once).All in all, be careful and if possible make some research to figure out what your cellphone does and check it against your bill because you will probably save some (or a lot of) money.
Cheers,
D.

Disclaimer: All the information posted is intended for illustrative and educational purposes only. I just want to show you that it’s possible to set up the iPhone SDK on a Virtual Machine. Please, BUY an Apple Mac OS X License if you are going to use this and BUY a Mac computer (Apple’s EULA agreement states that you cannot run Mac OS X under non Apple hardware).

In this post I will try to explain how to set up the SDK for iPhone OS 3.1 on a PC running Windows (Vista 64 in my case). From the readme file of the SDK you can read:

Xcode 3.1.4, when used for Mac-only development, is compatible with Intel and PowerPC Macs running Mac OS X Leopard 10.5 and later. Use of the iPhone SDK requires an Intel-based Mac running Mac OS X Leopard version 10.5.7 or later.

So we need a Leopard 10.5. By googling a little bit you will realize that there are some modified ready-to-use Leopard images out there that you can download and run out of the box on VMWare.

I’m running a 10.5.2 version (which takes about 5 mins to boot on my quad core). Once you get a Mac OS X running on your PC, you can download the free iPhone SDK from developer.apple.com and install it.

Mac OS X Leopard on VmWare under Vista

The iPhone SDK for OS 3.1 won’t install under a version prior to 10.5.7 so I had to ‘trick’ the installer rather to update the Mac OS X which seems to be a painful process. To do this, you have to modify the /System/Library/Core Services/SystemVersion.plist and change both the ProductUserVisibleVersion and ProductVersion keys to 10.5.7.

With this done, I selected just the SDK for 3.1 (to save space in my hard disk) and the installation process begins.

Custom Install  And 3.5 hours later….  Install Succeeded

Once you have the iPhone SDK installed, you can run Xcode (from SpotLight) and launch a new project using a template just to try it out on the iPhone Simulator:

Xcode and simulator   Xcode and simulator (2)

At this point you can develop your own iPhone applications and test them on the simulator. Also, if you joined the Apple developer program (the standard one is $99) you can test them in your iPhone as well.

If you’re planning to play around with the SDK I strongly recommend you to sign up on the iPhone Dev Center because there are lots of resources available: Getting started documents, videos,  sample code, etc.

More to come,

Daniel

I’ll briefly explain how to generate the signature file for a given library in order to import it from IDA Pro and get the library functions identified by the disassembler (which can save you hours from digging into ‘well-known’ functions).

Requirements: FLAIR tools installed.

Execute the COFF parser

> pcf ms32.lib miracl

ms32.lib: skipped 0, total 432

>sigmake miracl miracl

You might get collision errors here:

See the documentation to learn how to resolve collisitions.
: modules/leaves: 9021136/432, COLLISIONS: 382

At this point, just edit the .exc file, remove the comments in the first lines and re-execute the sigmake command.

Now you’ll see a miracl.sig ready to be imported from the FLIRT signatures window in IDA Pro.

EOF,

Daniel Álvarez

Hello,

I’ve developed a little application that switches the audio output from the rear speaker to the front one and viceversa. This is useful for VoIP applications which are quite unusable without headphones since the audio comes from the back speaker. It just runs for 10 minutes and it’s supposed to work at least with the latest HTC models.

Download PocketPC Trial version:

PPC-AudioSwitch.zip

Download SmartPhone Trial version:

SmartPhone-AudioSwitch.zip

Don’t hesitate to contact me for any further information.

Warm regards,

Daniel

When I had to write some formulas in the blog I used to render them from LaTeX to images using some websites such as Online LaTeX Equation Editor. It has the disadvantage that you’ve got to write the equation, render it, save it to your harddisk and then upload to the WordPress file manager. Now, thanks to an interesting plugin written by Steve Mayer you can embed its usage into WordPress just by typing the LaTeX commands between special tags.

\sum_{n=0}^{\infty}\frac{(-\phi^2)^n}{(2n)!}

It uses MimeTeX  which is an standalone program that directly renders LaTeX expressions into images without using the entire TeX package or its fonts. Thus, it’s a simple, lightweight and elegant solution ready to be used in your websites or blogs.

D.

Golden Cup

 

Last week, we attended to Campus Party in Valencia. At CampusBot area, some robots competitions took place along the week and we had our line followers ready to fight. The results were pretty good: In the qualifying session on Tuesday we got the fastest two times with our two robots and in the finals on Saturday (being held at Ciudad de Las Artes y Las Ciencias) we managed to win the two first places in the podium !

 Here you can see some videos:

 

 

 

Slayer S8 during our first training rounds:

Slayer S8 from a speed view like if it was an F1 camera :-) running at more than 2,5m/s:

Slayer S8 at Semifinals Round against the later 4th classified:

It was a great week and the robots performed pretty well in such a speedy track. I might upload some more media when I finish collecting all the videos and pictures from the event.

My colleague Alberto Calvo and me are already thinking in our next robot which will have some kind of inertial control based on gyroscopes and accelerometers. I’ll keep the blog up to date.

Special thanks to our teammates and friends Luis-Ángel Gónzalez and Daniel de la Torre who drove more than 800 km by car just to watch the final rounds and support us (well and to have a nice Paella in front of the beach). Thanks guys!

More to come,
Daniel

I have worked on several platforms based on ARM cores: ARM7, ARM9 and XScale. ARM architecture has been present in more than 2 billion embedded products over the last 10 years, ranging from cell phones to automotive braking systems. I think ARM architecture is great for embedded computers and I needed to learn it so that I could get its best.

ARM System Developer’s Guide

The best book I found on this is ‘ARM System Developer’s Guide’ by Andrew Sloss (ARM Inc.), Dominic Symes (ARM Ltd.) and Chris Wright (Ultimodule Inc.). It covers all the ARM cores, XScale processors, demonstrates how to implement DSP algorithms, describes cache technologies that surround the ARM cores, as well as efficient memory management techniques.

Among the tasks I’ve had to deal with I’d point out Artificial Vision and Vocoders implementation for being computationally expensive.

In vocoders implementation and optimization case, I had to face some large of Digital Signal Processing issues which leaded me to write assembly code in order to get the best performance. Also I had to focus in the cache usage because it can speed up the execution time amazingly. Not to mention avoiding pipeline stalls and efficient use of the registers. The mentioned book covers all these topics both with theory and practical examples. There’s a dedicated chapter about DSP which even includes source code ready to use.

Even if you don’t need to write assembly code you can learn how to write efficient C code for ARM. I will show a simple example which can improve ‘intensive loop’ codes:

int checksum(int *data)
{
        unsigned int i;
        int sum=0;
        for(i=0; i<64; i++)
        {
                sum+=(*data++);
        }
}

This compiles to:

        mov     r2,r0           ; r2=data
        mov     r0,#0           ; sum=0
        mov     r1,#0           ; i=0
checksum_loop
        ldr     r3,[r2],#4      ; r3 = *(data++)
        add     r1,r1,#1        ; i++
        cmp     r1,#0×40        ; compare i,64
        add     r0,r3,r0        ; sum+=r3
        bcc     checksum_loop   ; if(i<64) loop
        mov     pc,lr           ; return sum

The above code is not efficient, we can avoid the 3 steps loop: ADD 1 to i, comparison and the conditional branch instruction.
Instead:

int checksum_eff(int *data)
{
        unsigned int i;
        int sum=0;
        for(i=64; i!=0; i—-)
        {
                sum += *(data++);
        }
        return sum;
}

As you can see, we just rewrote the loop to be descendent rathern than the previous incrementing loop. Let’s have a look at the compiled code:

        mov     r2,r0                   ; r2=data
        mov     r0,#0                   ; sum=0
        mov     r1,#0×40                ; i=64
checksum_2_loop
        ldr     r3,[r2],#4              ; r3=*(data++)
        subs    r1,r1,#1                ; i– and set flags
        add     r0,r3,r0                ; sum+=r3
        bne     checksum_2_loop         ; if (i!=0) loop
        mov     pc,lr                   ; return sum

As you can see, the loop work is done entirely by the subs and bne instructions. The comparison with zero is free since the result is stored in the condition flags. Thus we can see that it’s more efficient to make decrementing loops in ARM than incrementing ones.

Let’s have a look at the way one could have written the same function in C without taking efficiency into account:

int checksum(int *cata)
{
        char *i;
        int sum=0;
        for(i=0; i<64;i++)
        {
                sum += data[i];
        }
}

And the compiler output:

        mov     r2,r0                   ;r2=data
        mov     r0,#0                   ;sum=0
        mov     r1,#0                   ;i=0
checksum_loop
        ldr     r3,[r2,r1,lsl #2]       ;r3=data[i]
        add     r1,r1,#1                ;r1=i+1
        and     r1,r1,#0xff             ;i=(char)i
        cmp     r1,#0×40                ;compare i and 64
        add     r0,r3,r0                ;sum+=r3
        bcc     checksum_loop           ;if(i<64) loop
        mov     pc,lr                   ;return sum

At first, one may think that declaring i as char uses less register space or less space on the ARM stack than an int. On ARM these assumptions are wrong and that’s why the output code includes the AND instruction with 0xFF which actually slows the execution without saving space. So our checksum_eff function is pretty much faster without not so much effort just by knowing a little bit about ARM architecture.

Rewriting C functions is the first thing that should be done when optimizing before digging down into assembly. Special care must be taken in those functions with nested loops or with too many iterations. It’s also useful some profiling tool like Intel VTune Performance Analyzer to check if all our optimizations are really optimizations and how much we have speeded its execution up.

Hope you found this article useful,

Daniel