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
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.
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 :-/
well, first i want to thank the guy i wrote about there:
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 0x34, both client and server modify their encryption tables. This results in totally wrong en/decryption.
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 0x40, 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?
i released the latest version of the CEntrilo binaries for QVGA, VGA and MDA/XDA devices.
please test them – i just simulated them in the emulator.
you should see improved connection handling and better sound recording.
please report when you still see hangups after some time.
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
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”.