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

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

http://www.g3gg0.de/wordpress/archives/16

more than half a year later he contacted me and sent twice the money he promised before.
obviously he really was busy for long time ;)
thanks Mr. S.C. ;)
okay now about Ventrilo v3.0.x:

i had a look at the protocol. the connection setup is nearly the same. but right after the sever sends the command 0×34, both client and server modify their encryption tables. This results in totally wrong en/decryption.

see http://g3gg0.de/projects/CEntrilo/modify_crypt_buffer.html
and http://g3gg0.de/projects/CEntrilo/modify_crypt_buffer_c.html
its from Ventrilo Server for Linux v3.0.1

i’m not exactly sure what sense this change makes. it’s re-allocating the buffer with a minimum size of 0×40, fills it up with [length]+pos byte values and adds up the old values.
that looks like some weird try to prevent another reversing?!

anyone an idea whats the sense of this code?

a guy asked me to fix all the problems and promised me $100 for doing that quickly.
but guess what…. even 6 weeks after he said everything is perfect, he still didnt send
anything.. until now i havent heard anything from him :-S

thats life.

so if you find it useful, even just $5 or 5€ will make me happy since it shows that you honour my work.
if you want to contribute money, please send it to the paypal account “geggo <at> g3gg0.de”.

thanks :)