Be careful, this must be considered as a MALWARE!
For starters, the installer is packed with UPX but it doesn't need any serial for the installation to take place. The serial is only there to activate the software.
After installing the software, you get a bunch of executables :
- cdtsvc.exe : service of download control
- cdtsvc64.exe : same as cdtsvc.exe but for 64 bits
- cdtupd.exe : probably the executable for checking updates
It seems that none of the executables are packed or whatsoever.
Just analyzing cdtsvc.exe, I got quite a bunch of informations on the executable itself.
Looking at C string references and unicode strings, you get to have those informations :
Path : C:\\Documents and Settings\\jbroutin\\Mes documents\\Visual Studio 2008\\Projects\\ddp-hadopi\\hadopi-client-gui\\trunk\\Release\\cdtsvc.pdb RSA Key : BgIAAACkAABSU0ExAAQAAAEAAQCzLXpRE/3Y3n9F1lf2wlRsQGzgs4gfBRNj/PmPArxOtJ1Z1ra8bTktvDCyLsImEc12d6DvVeYsAIgjMZNxQqczzhEla7ZAXQXOOBo38ZUZot961pXx76GCRMAfAYz2S3O79bBGCtJ5wh3UcmvAUcEmdqLzFebBw7Ef+qxyfgamyw== URL : http://update-cdt.nordnet.fr/hadopi-server-technical-ws-1
The author of the software is named jbroutin, chances are that his last name is Broutin. It clearly show HADOPI projects and using Visual Studio 2008.
Looking at the code, we can confirm that he's using C++ or some other kind of oriented object langage (there are lots of get() and set()).
Nordnet contacted Bluetouff so the URL makes sense. It might be the URL for the Java Applet Bluetouff was talking about. I just can't imagine the damage it could be done injecting code in it.
For the RSA Key, I don't know what it's for for now. The RSA Key shown here is encoded using Base64 for those who were asking themselves.
Looking more, we see stuffs like these :
hadopi
Ok we now know that we really are dealing with some HADOPI crap.
going further :
HTTP/1.0 [...] Content-Type: application/x-www-form-urlencoded
No wonder that Bluetouff get to have a lot of informations using Wireshark ...
We haven't even looked at the code yet that we have quite some infos ...
Cross-referencing the string with "HTTP/1.0" we land in a subroutine at address 0x405574.
This routine seems to construct some kind of URLs and make a request with it.
Looking at where it's called from, you get a bunch of function but at the top is 0x4027EB. This seems to be the main routine which set up the service and stuffs.
I look at one of the functions that called directly 0x405574 and there was 0x406991 : this function seems to check for some kind of updates and licence check too but I dunno, what would be cdtupd.exe then?
From 0x406991 I got this sequence of numbers :
0.2.1.1.3 0.2.1.3.2 33.1.1.1 33.2.1.3 33.2.2.1 33.2.1.2
I don't know about the first two (they might be OID, reverse DNS, or something else).
For the second groups, they look like IPs.
I tried to have a DNS query with all of thoses, but I only get an answer for 33.1.1.1 :
m_101@m_101:~$ nslookup 33.1.1.1 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: *** Can't find 1.1.1.33.in-addr.arpa.: No answer Authoritative answers can be found from: 33.in-addr.arpa origin = CON1R.NIPR.MIL mail addr = DANIEL\.KNOPPS.DISA.MIL serial = 2010061101 refresh = 10800 retry = 900 expire = 1209600 minimum = 10800
I also found some strange stuffs by cross referencing an API called CreateToolhelp32Snapshot() . I landed in routine 0x40C225, why the hell is the software going around all the processes?
I didnt dig further but it seems strange to me.
That's all I got for today, it took me around 20 minutes to get all that ... what about the people who spent hours on this? They might already have a clone or something else entirely.
m_101
- link : Orange HADOPI Software
- link : Installed files
And http://update-cdt.nordnet.fr/web-console/ as a veric basic admin password...
RépondreSupprimer"I also found some strange stuffs by cross referencing an API called CreateToolhelp32Snapshot() . I landed in routine 0x40C225, why the hell is the software going around all the processes?
RépondreSupprimerI didnt dig further but it seems strange to me."
Please, Orange states that the tool prevents some P2P software to work by looking for their names in the processes list. So it's no surprise that it digs through the processes list...
The rest of the article is good, but you could have checked this.
Regarding the CreateToolhelp32Snapshot() and process listing, I guess the software tries to find if some kind of P2P software is running, and then kill it. You might check for strings such as "eMule" and co ... :-)
RépondreSupprimerYeah true enough.
RépondreSupprimerAs I said it was a quick analysis, if I had more time, I would have done a more thorough analysis.
Of course it search for P2P software, but how it's done, I only have an approximate idea.
For now we can see a MD5 checksum like "f1afa88991ad63867e2c70e3407c4b6a" and a file named "cdt.sig" which must contain the other signatures (so pretty easy to bypass even if the thing is installed ... a pure failware). There also seems to have some kind of pipes : \\.\pipe\CTPipe .
It's good news that it doesn't use DLL Injection techniques (haven't seen any reference to CreateRemoteThread(), VirtualAllocEx() or LoadLibrary() functions) or do deep packet inspection.
If I had more time, I would have done a more thorough analysis. Seeing how far I went without even launching the code or reading that much disassembly ... it's already pawn so no point in going any further.
For those of you who were asking themselves how we got all those IP's, it's a pretty simple script that F0o wrote :
while true; sleep 5; do wget -qO - http://195.146.235.67/status?XML=true | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' >> /tmp/out.tmp; done
The JBoss software they used is vulnerable and hackable as hell.
FYI, the md5 hash seems to be used as a password when communicating with the remote server..
RépondreSupprimer