No idea why i never realized its bugs (?)

Revision: 3585
Author: geggo
Date: 19:55:28, Mittwoch, 19. August 2009
Message:
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
Message:
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

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:

What we can see there? Well, not much.
Just the usual “who are you?” stuff followed by a CIPHER COMMAND.
After that, all the traffic is encrypted using specified cipher.

I uploaded a dump here, a short video is here ;)

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 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)

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? :-/

http://g3gg0.de/projects/NETrilo/NETrilo_alpha.exe

its just for connecting to v2.3 servers, browsing channels
and seeing what other users do :)

should work on linux/win32
(just tested win32 yet)

please reply, if it works for you :)

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…

what?

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.

btw:
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 :-/