[ARMada] small updates

there are small updates to ARMada. let me cite the SVN log:

Revision: 3585
Author: geggo
Date: 19:55:28, Mittwoch, 19. August 2009
fixed parameter limit check for ADD SP, val operation
Modified : /trunk/nokia/ARMada/compiler.c

Revision: 3579
Author: geggo
Date: 19:29:51, Mittwoch, 19. August 2009
fixed ADDSP, ADDPC, SUBPC descriptions to match new ADD/SUB type opcode
fixed ADD Rn, SP, val opcode
fixed .code description
Modified : /trunk/nokia/ARMada/ARM_Compiler.aps
Modified : /trunk/nokia/ARMada/ARM_Compiler.rc
Modified : /trunk/nokia/ARMada/ARM_Compiler.vcproj
Modified : /trunk/nokia/ARMada/code.c
Modified : /trunk/nokia/ARMada/code.h
Modified : /trunk/nokia/ARMada/compiler.c

[GSM] New FFT Visualizer Component

This time I built a new FFT Visualizer Component.
It’s a split “FFT Plot”+”Waterfall” view, which has the “FFT Plot” in the top and the waterfall in the bottom half.

In the video (watch fullscreen in HD mode) you cannot see the dB markers very clearly.
These are on the left and the right border of the “FFT Plot” (top part) and labelled in 50dB steps.

The “Waterfall” has a configurable upper and lower dB limit (changed with mouse wheel, see lower left corner).
Values above the upper limit are drawn cyan, those with a dB value lower than the lower limit are drawn black.
The values between are colored with a color between.

Here a video of that component:

[GSM] Code updates

On the videos you’ve maybe seen that my tool shows the bursts in some plot window. I used GDI for drawing the lines… damn this is soooo slooow…

Today i decided to switch to DirectX drawing for speedup. Ater some hours of playing around, I found out how to draw a plot easily. (using DrawUserPrimitives with LineStrip vertices)

The graph is reeeeaally fast now (displaying bursts in realtime) with just about 5% of CPU load. kewl :)

But the DirectX assemblies Microsoft provides seem to work only with x86.. oouch. So I looked for some solution and found SlimDX which is a managed DirectX library. Using this library I can now run my tools in x64 mode again.

How much faster my tool is in x64 mode?

Hm I think about 0.001% up to 0.002%… But hey, running 64 bit code is much cooler :)

I uploaded two dumps generated with my GSM Analyzer:

  • Dump 1 contains ~15 min dump without “SYSTEM INFORMATION” or “PAGING REQUEST” messages except those with an IMSI
  • Dump 2 contains just a few seconds with everything and is really ugly to read for this reason

[GSM] GSM Analyzer

As described in earlier blog posts, I coded a driver for an USB radio receiver which is comparable to USRP. So I’m able to “record” radio data and save it, or process it on-the-fly with some tools.

GSM Analyzer is a C# tool that demodulates and decodes the GMSK signal which GSM uses. Furthermore it decodes the L3 (Layer 3 Protocol) messages sent in the broadcast channel (BCCH). This means, I’m able to “tune in” into some GSM radio channel and sniff the packets which the base station (BTS) is sending. Usually thats just really public information like the provider ID, information about the network and such things. Nothing interesting.

People who know the nokia net monitor would just look up that in the phones menu…
I “just” select some radio frequency and look that up there using my tool ;)

That project is really just for fun. Some people call me crazy. No idea why they do that. Thats really not hard to decode. And it has nothing useful yet. Okay… if I’m able to decrypt the A5 crypted SDCCH/TCH traffic, that whole story really would get interesing. But thats still pure theory yet.

Maybe I will describe that stuff more in the near future. Maybe I will release the source code. Maybe I won’t :)

See the project page for some videos. (the text is the same, except for the video description)

[.NETrilo] another test release

i was so anxious to make .NETrilo usable so i spent another day implementing stuff.

today i implemented a DirectSound plugin (“snd_DirectX.dll”) that supports just playback for now. recording still has to be done, but that has to wait until i start the “input” stuff. (i.e. “inp_DirectX.dll”)

i also implemented GSM decoding. i used a version of the GSM codec that was ported to java and ported that to C#…
it performs very well… but the processor usages unbelieveable high :-/ (10 times more than the native client)

not sure, but i should make extra modules for the codecs. so i’m able to use different licenses for each module and we are able to use faster native libs for the standard platforms (win32/linux) and .NET versions of the codecs for others.

someone wants to help? :-/

[.NETrilo] Whats going on?

not much! :)

currently i’m working on my diploma thesis.
thats something related to the “USB-RX”-project i wrote before.

but sometimes i need to relax. and what do i do when i’m relaxing?
yeah… programming some unnecessary stuff :)

this time i started .NETrilo, a ventrilo client based on microsoft .NET – i really love .NET, did i tell ya?
at least i love C# – its like C, just much more comfortable. unlike C++ it has a much cleaner design.
as you know CEntrilo was just a dirty hack… really ugly code hacked together. ugh…

so i started .NETrilo as a multi-protocol ventrio client using plugins.
each ventrilo protocol (or maybe others?) is loaded as a seperate DLL – v2.3 is the first i’m doing now (“prot_Vent23.dll”).
also the GUI will be based on plugins. you can load “ui_Forms.dll” and/or “ui_WPF.dll”, maybe also “ui_GTK.dll” etc.

why plugins?

well, i’m not sure for whom this client is interesting, so i decided to place all the platform/protocol dependent things in loadable plugins:

  • is it the normal Win32 user who just wants some nifty feature .NETrilo will get?
    maybe the LUA support i want to implement for user functions?
    or the possibility to connect to different ventrilo server versions in parallel with just one client?
    or is it just the feeling to use a plugin-customizable client..?
  • or is it the Linux/OS X/*.unix gaming user who wants to use a *cough* little bit more native client?
    a client that supports PTT using a native plugin named “inp_X11.dll”?
    or uses a native GUI using “ui_GTK.dll”?
  • perhaps it will be the average Windows Mobile 5/6/7 user who just wants to have a better client :)
  • (dreaming now…) or some symbian-freak who has the latest .NET environment installed and also wants to speak with his ventrilo-friends…


ok, the last two are really some “maybe-it-works” points. really have no clue if i can get the code efficient enough to run on a symbian phone…
or if i can manage to decode the GSM packets somehow on this platform.
but i’m trying to push .NETrilo into this direction.
at least i want not to sit in front of my computer saying “idiot, why didn’t you….” when trying to port it to symbian/WinCE.

anyone an idea where to get a C# implementation of the GSM algo? don’t want to port that ugly C code to C# :(
or does anyone know how to get and interface a GSM codec on symbian phones using .NET?

now you ask what currently works?

hmmm not much :)

  • i can connect to ventrilo v2.3 servers using username/password
  • receive the list of users and channels
  • have some kind of GUI that looks like ventrilo but just has a functional “Connect” button
  • not more yet :)

the next steps are really no big problems – just writing some boring GUI code…
…and some porting of CEntrilo code to cleaner C# code.

when will it work?

no idea, really :)
i will update you if there are some news.
but first i have to finish my diploma thesis :-/

[reciva] Encryption on Reciva Barracuda

I helped a friend in reversing the firmware of some reciva internet radio module. Here are the results, explained in a few words he wrote down for interested readers.

Downloading from the Reciva Servers

Reciva has extended the open-source curl program for doing firmware downloads
(and possibly more) from its servers. They do not offer the source code which
is probably ok because curl is covered by an MIT/X derivate license.

If you log into the Linux system which is running on the Barracuda radios,
you can use curl to do downloads from the Reciva servers. e.g.:

curl reciva://copper.reciva.com:6000/service-pack/sp255-c-106.bin > sp255-c-106.bin

When looking at the communication, it appears to be encrypted. So your radio
talks home and you don’t know what it’s talking which isn’t exactly very
polite for hardware you own. When looking at the exchanged data more exactly,
the first 8 bytes transmitted to the Reciva server is the serial number, so
Reciva knows which radio has downloaded which software. The first answer
sent by the Reciva server are also 8 bytes which change every time that
something has been successfully downloaded. These 8 bytes seem to be random,
but they are not the encryption key. Instead, the encryption key is calculated
from the random bytes. This is where the sernum daemon comes into play.

The sernum daemon

If you look at the process list, you’ll notice a program named “sernum”. It
is responsible for reading the serial number and for handling encryption
keys (see the next chapter on how this is done). Both curl and the main
radio application (named “ir”) are talking to this daemon via a unix socket

The protocol is simple: sernum clients issue requests on the socket, and the
sernum server responds. The following requests are known:

(“>” means client to server, “<” means server to client)

Read radio serial number.

> \x03
< \x00\x01\x23\x45

Give encryption keys:

> \x01\x8c\xe3\xbe\xb8\x6e\x2c\x26\x7f
< \x1e\xc9\x50\xc1\x66\xfa\xae\x84       // Download authorization token
> \x00\x1e\xc9\x50\xc1\x66\xfa\xae\x84
< \xab\x81\x64\x5e\x21\xaf\xaa\xf1       // DES keys
> \x00\xab\x81\x64\x5e\x21\xaf\xaa\xf1
< \xb2\x47\x30\x32\x87\x13\x98\x3a    // 3DES key, 1st part
> \x00\xb2\x47\x30\x32\x87\x13\x98\x3a
< \x45\x31\x39\xd9\xcd\x9f\x8e\x11     // 3DES key, 2nd part
> \x00\x45\x31\x39\xd9\xcd\x9f\x8e\x11
< \x61\x38\xb8\xc1\xde\x1e\x33\x4a     // 3DES key, 3rd part

Read version (probably the sernum protocol version):

> \x04
< \x02

The sernum daemon doesn’t contain the serial number, nor does it perform the
actual encryption. This is done by the Atmel MCU instead.

The Atmel MCU

The sernum daemon talks to the Atmel CPU via a three wire serial protocol
(data, clock, acknowledge) by directly accessing the S3C2410 GPIO registers
(via mmap()). The protocol used is similar to the /tmp/sernum one, but
different command bytes are used. The algorithm used is probably XTEA, but
the encryption key is unknown and probably depends on the serial number.

The reciva protocol

Now, back to the download process. As already mentioned above, the client
sends its 8 byte serial number (ASCII encoded) to the server, which responds
with an 8 byte challenge. From this challenge, the client calculates 3 byte
sequences (download authorization token, DES key, 3DES key) with the help of
the sernum daemon (which in turn uses the Atmel MCU).

The rest of the protocol is based on fixed size blocks with 3 types of blocks:
Type 1: Download request block (256 bytes, DES-CBC encryption)
Type 2: Data block (256 bytes, DES-CBC encryption)
Type 3: Check block (192 bytes, 3DES-ECB encryption)

After the two initial PDUs (serial number, challenge), the client requests
a file by sending a download request block. This block contains:
8 byte authorization token + filename (‘\0’ terminated) + pad + checksum

The whole 256 byte block is then DES encrypted.

The checksum is the last byte of the block and contains the modulo 256 sum
of the first 255 bytes. The pad seems to be random data, but does never
contain an 0x00 byte.

Now, the server sends the file contents in data blocks. After every 20th data
block, a check block is sent.

The first data block contains an 8 byte header which contains the file size
(4 bytes) and an unknown (maybe fixed) value (also 4 bytes). The header
is followed by 246 bytes of payload, a single 0x00 byte and a checksum
(again, a simple modulo 256 sum).

All further (i.e. non-first) data blocks contain 254 bytes of payload,
a single 0x00 byte and a checksum.

All data blocks are DES encrypted, but note that the data block DES stream is
encrypted independently of the download request block.

The check blocks do not contain any actual data. Instead, they repeat the
last 192 bytes of the encrypted (!) preceding data block, with a 3DES-ECB
encryption applied. In other words, the last 192 bytes of the already DES
encrypted preceding data block is encrypted again (with 3DES-ECB this time)
and then sent as some sort of check.

The DES and 3DES ciphers use fixed initialization vectors which are as
For DES: \xbd\xe7\x32\x66\xb9\x46\xf3\xab
For 3DES: \xed\x9e\xa8\x97\x7c\xee\xc8\xac

[CEntrilo] public SVN access


since i dont find some spare time to update CEntrilo, i made the SVN public.

username: centrilo
password: behave!

simply get the source, look how it works and create a new, CLEAN tool from it.
would be really cool if you can keep the core platform independent.
i also somewhen tried to make a symbian client, but could not get beyond
connecting and hearing some noise when people talk ;)