{
	"id": "ae444f77-492c-4142-b3d5-baf631651ad0",
	"created_at": "2026-04-06T00:12:09.087215Z",
	"updated_at": "2026-04-10T03:30:57.34056Z",
	"deleted_at": null,
	"sha1_hash": "bd9ed4cee54d672a809a865a40d67ec167b2acf6",
	"title": "Virus Bulletin :: Andromeda 2.7 features",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1448156,
	"plain_text": "Virus Bulletin :: Andromeda 2.7 features\r\nBy Suweera De SouzaFortinet, CanadaNeo TanFortinet, CanadaEditor: Helen Martin\r\nArchived: 2026-04-05 18:07:14 UTC\r\n2013-08-01\r\nAbstract\r\nA new version of the Andromeda bot was recently spotted in the wild with strengthened self-defence mechanisms and\r\nnovel methods for keeping its process hidden and running persistently. Moreover, its communication data structure and\r\nencryption scheme have changed, rendering previous Andromeda IPS/IDS signatures useless. Suweera De Souza and\r\nNeo Tan take a detailed look at Andromeda 2.7.\r\nCopyright © 2013 Virus Bulletin\r\nRecently, we found a new version of the Andromeda bot in the wild. This version has strengthened its self-defence\r\nmechanisms by utilizing more anti-debug/anti VM tricks than its predecessors. It also employs some novel methods for\r\ntrying to keep its process hidden and running persistently. Moreover, its communication data structure and encryption\r\nscheme have changed, rendering the old Andromeda IPS/IDS signatures useless.\r\nIn this article, we will look at the following:\r\nIts unpacking routine\r\nIts anti-debug/anti VM tricks\r\nIts malicious code injection routine\r\nThe interaction between its twin injected malicious processes\r\nIts communication protocol, encryption algorithm and command control.\r\nOverview of unpacking routine\r\nThe sample we analysed is firstly packed with UPX. However, once unpacked, the code inside is another custom packer.\r\nThis custom packer creates dynamic memory and decrypts code into this memory (Figure 1). It jumps to a lot of\r\naddresses by pushing the offset onto the stack and then returning to it. The code in memory calls VirtualAlloc three\r\ntimes. The first allocated memory is used for storing bytes copied from the original file. Those bytes are then copied\r\nover to the third allocated memory where they are rearranged by swapping bytes (using the algorithm shown in Figure\r\n2). Finally, the partially decrypted bytes are copied to the second allocated memory, where the data is decompressed\r\nusing the aPLib decompression library. The result is a PE file which is then written over the original file image, and the\r\nanti-debugging tricks are carried out from here. Figure 1 gives an overview of the unpacking routine.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 1 of 14\n\nFigure 1. The unpacking process.\r\nFigure 2. Algorithm showing how the bytes were swapped.\r\nThe way to the real routine\r\nThis version of Andromeda employs many anti debug/anti VM tricks, which result in the bot switching to a pre-set fake\r\nroutine in order to prevent it from running in the VM environment, being debugged or monitored. The purpose is\r\nobvious: to prevent analysts from being able to access the real malicious routine. In the following sections, we’ll take a\r\ndetailed look at these defence mechanisms.\r\nAnti-API hook\r\nThe sample allocates another section of memory for its anti API hooking technique. The technique consists of storing\r\nthe first instruction of the API to memory, followed by a jump to its second instruction in the DLL.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 2 of 14\n\nFor example, in Figure 3, memory location 0x7FF9045E stores the location of memory 0x7FF80060, which is where the\r\nfirst instruction of the API ntdll.RtlAllocateHeap is stored, followed by a jump to the second instruction in the DLL.\r\nFigure 3. Anti-API hooking.\r\nCustomized exception handler\r\nA pointer to a handler function is passed to the SetUnhandledExceptionFilter API. The handler is called when an access\r\nviolation error is intentionally created by the sample when it tries to write into the file’s PE header. The code in the\r\nhandler is only executed if the process is not being debugged.\r\nThis function (Figure 4) gets the pExceptionPointers \u003eContextRecord (the second DWORD of arg_0) in order to set the\r\nlocation of the real payload (sub_401EA5) to the EIP (ebx+0B8h) upon return. It also gets the ESP (ebx+0C4h) and then\r\nsets the two arguments which will be passed to the payload function: arg0 to dword_402058 and arg1 to sub_401AA2.\r\nDword_402058 points to the encrypted code and sub_401AA2 points to another decryption routine which will be\r\ninjected by the code decrypted from dword_402058.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 3 of 14\n\nFigure 4. UnhandledExceptionFilter function.\r\n(Click here to view a larger version of Figure 4.)\r\nAnti-VM and anti-forensics\r\nThe GetVolumeInformationA API is called on drive C:\\ to get the name of the drive. Then the bot calculates the CRC32\r\nhash value of the name (Figure 5). If the hash value of the drive name matches 0x20C7DD84, it will bypass all the anti-debugging and anti-VM checks and invoke the exception directly. When the CRC32 hash is reversed, one possible result\r\nis ‘BVabi’. This could be the name of the author’s C drive, so that he/she could skip all the trouble when debugging\r\nhis/her own program.\r\nFigure 5. Checking if the drive name’s CRC32 value is 0x20C7DD84.\r\nIf the hash value of the drive name doesn’t match, the following anti-debug/anti-VM tricks are employed:\r\n1. Iterating through process names and computing their CRC32 hash values: if a hash value matches any of those\r\non a list of hash values of VM processes (Figure 6) and forensics tools (regmon.exe, filemon.exe, etc.), this\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 4 of 14\n\nindicates that the debugging process is inside a sandbox environment and being monitored.\r\nFigure 6. Matching the process with CRC32 hash values.\r\n2. Trying to load the libraries guard32.dll and sbiedll.dll, which belong to Comodo and Sandboxie respectively. If\r\nthe libraries can be loaded successfully, this indicates that the debugging process is inside a sandbox\r\nenvironment.\r\n3. Querying for a value in the system\\currentcontrolset\\services\\disk\\enum registry to search for the presence of any\r\nvirtual machine (Figure 7).\r\nFigure 7. Querying for virtual machines\r\n4. Calling the opcode rdtsc, which returns the processor time stamp. When first called, it saves it in edx, and the\r\nsecond time it saves it in eax. The registers are subtracted and if the result of the tickcount is more than 0x200h,\r\nthis indicates that the process is being debugged.\r\nIf the bot does detect the presence of either a debugger or a virtual machine, it decrypts the dummy code. This code\r\ncopies itself under %alluserprofiles% as svchost.exe with hidden system file attributes. It then writes itself in the\r\nregistry HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run as SunJavaUpdateSched. A socket is then created to\r\nlisten actively, but no connection has been made previously.\r\nData structure of encrypted routine\r\nAs mentioned, the bot will decrypt the code as the next routine, whether dummy code or a useful routine. The encrypted\r\ncode of the file is contained within a specific structure that the file uses when carrying out its decryption routine. In this\r\nsample, there are three sets of encrypted code which represent three different routines. One routine contains dummy\r\ncode that is decrypted only when the sample is being debugged or run in a virtual machine. The second routine contains\r\ncode that injects itself into another process, whereon the third routine is decrypted in that process. The data structure is\r\nshown in Figure 8.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 5 of 14\n\nFigure 8. Data structure used by the bot.\r\nThe encrypted data, which is located at 0x28h after the structure, is decrypted using RC4. The key used is a fixed length\r\nof 0x10h and is located at the beginning of the structure. The decrypted code is further decompressed into allocated\r\nmemory using the aPLib decompression library.\r\nTwin malicious injected processes\r\nThe bot will inject its core code into two processes after successfully bypassing all the anti-debug/anti-VM tricks. First,\r\nlet’s see how the malicious code is injected into processes before we shed light on how the two injected processes\r\ninteract with each other.\r\nCode injection routine\r\nThe bot calls the GetVolumeInformation API on C:\\, to get the VolumeSerialNumber. It then checks whether the\r\nenvironment variable ‘svch’ has already been created [1]. If it has, then it will inject itself into svchost.exe. If the\r\nenvironment variable is not present, it will set the environment variable ‘src’ to point to its own file path and then inject\r\ninto msiexec.exe. This suggests that the bot injects its code into two different processes at different instances. We shall\r\nsee why in the next section.\r\nIt then gets the Windows directory. Before injection, the bot needs to find the location of these files (svchost.exe,\r\nmsiexec.exe) in the Windows directory. Thus, it calls ZwQueryInformationProcess and accordingly concatenates the\r\nprocess name with \\System32 for 32-bit and \\SysWOW64 for 64-bit systems.\r\nThe injection process involves several steps:\r\n1. As with the previous versions, the malware calls CreateFile to get the handle of the file it wants to inject. It then\r\ngets its section handle by calling ZwCreateSection, which is used by ZwMapViewOfSection to get the image of\r\nthe file in memory. From this image, it extracts the size of image and the address of the entry point from the PE\r\nheader.\r\n2. A memory address with the same size as that of the image of the file it wants to inject is created with\r\npage_execute_readwrite access. Then the image of the file is copied over to this memory address.\r\n3. Another memory address is created with the same size as that of the image of the original bot file, also with\r\npage_execute_readwrite access. The original file is then copied over to this new memory address.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 6 of 14\n\n4. A suspended process of the file to be injected is created. The memory address containing the original file is\r\nunmapped. ZwMapViewOfSection is called with the bot’s file handle and the process handle (acquired from\r\ncreating the suspended file process). So now the injected file’s process handle has a map view of the botnet file.\r\nBefore it calls ResumeThread to resume the process, it changes the entry point of the injected file to point to its\r\ncode, which it has modified as follows:\r\npush \u003caddress of botnet code to jump to\u003e\r\nret\r\nTwin process interaction\r\nThe code that is injected into the process decrypts more code into memory using the methods described in the previous\r\nsection. This final decrypted code is the commencement of the botnet’s payload. In this version, Andromeda displays\r\nsome new techniques in its execution.\r\nFirst, it modifies the registry entry\r\nHKLM\\system\\currentcontrolset\\services\\sharedaccess\\parameters\\firewallpolicy\\standardprofile\\authorizedapplications\\list\r\nto the value of %s:*:Generic Host Process, which points to the path of the current process. This is done to allow the\r\nprocess to bypass the firewall.\r\nNext, it tries to determine whether the environment variable ‘svch’ has been set. If it has, it means that another instance\r\nof the file has been run. If it has not been set, then the malware has yet to inject itself into the other process.\r\nThe creation of two processes is important for the bot. One process is used to make sure that the copy of the bot which\r\nwill be created in %alluserprofile% is always present and that the registry entries have not been modified. The second\r\nprocess is used for connecting to the C\u0026C server and executing instructions based on the messages received.\r\nAdditionally, the two processes communicate with each other through an instance of creating a pipe connection. It is this\r\nconnection that enables either process to check that both instances of the bot are always running or to terminate the\r\nprocesses in the event of an update or installation. The analysis of this part has been divided into Process 1 and Process\r\n2, so as to better understand the communication between the two processes (Figure 9).\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 7 of 14\n\nFigure 9. The flow of communication between the two bot processes.\r\n(Click here to view a larger version of Figure 9.)\r\nProcess 1 (installation routine and watchdogs)\r\nThis part of code is executed when the environment variable ‘svch’ has not been found. The bot tries to connect to the\r\npipe name, which is ‘kill’ xor’ed by the VolumeSerialNumber. If it can connect, then the bot terminates the other\r\nprocess. This thread is created as a check to terminate the other bot process in the event of an installation.\r\nIt then tries to get the environment variable ‘src’, which was created before injection. The value contains the path from\r\nwhich the original file was run. It uses this path to create a copy of the original file before deleting it, and saves it in\r\n%alluserprofile% with a random filename.\r\nNext, the bot wants to enable the file to autorun, so it saves the path of the file in %alluserprofile% in the registry. At\r\nfirst, it tries to access the subkey \\software\\microsoft\\windows\\currentversion\\Policies\\Explorer\\Run in registry HKLM.\r\nIf it is unsuccessful, it accesses the subkey \\software\\microsoft\\windows nt\\currentversion\\windows in HKCU. The\r\nregistry that it accesses successfully is the one that is used throughout for any modifications (explained in pseudo code\r\nin Figure 10). Once it has accessed the registry, it sets the security key of the registry to KEY_ALL_ACCESS. The\r\nsecurity key is obtained by passing the string ‘D:(A;;KA;;;WD)’ to the\r\nConvertStringSecurityDescriptorToSecurityDescriptorA API, which converts it to a security key. Once it has set the\r\nsecurity key, it saves the path of the new file to the registry under the value of VolumeSerialNumber (for HKLM) or\r\nLoad (for HKCU). The original file in the old path is deleted and the environment variable ‘src’ is set, pointing to 0.\r\nFigure 10. Pseudo code of registry chosen.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 8 of 14\n\nAfter this, the bot creates two watchdog threads which are primarily used to keep re-setting the file and the registry\r\nentries if they have been modified. The first thread checks if any modification has been made to the filename in\r\n%alluserprofile%, or if it has been deleted. Then it creates the file again with the same filename. It accomplishes this by\r\nfirst saving the file to the buffer by calling ReadFile. Then it calls the FindFirstChangeNotificationW API, whose handle\r\nwill retrieve the changes made to the filename. If the handle is 0xFFFFFFFF, then no changes have been made, and it\r\nenters a loop. If a change has been notified, then it creates the file again with the same filename, and writes the contents\r\nof the file back from the buffer created by ReadFile.\r\nThe second thread checks if any changes have been made to a value in the registry. If a change has been made, then it\r\nresets the registry security key and the value in the registry. Notification of changes made to the registry is set by calling\r\nRegNotifyChangeKeyValue.\r\nThe bot then creates two environment variables – ‘ppid’, pointing to its process ID, and ‘svch’ with the value of 1. It\r\nthen runs the file that has been created in %alluserprofile%. After running the file, it tries to connect to the pipe ‘kill’\r\nxor’ed by the VolumeSerialNumber. Since the value of svch has been set to 1, the second process will create a thread\r\nthat creates the named pipe connection and executes a second thread to connect to the C\u0026C server. When the first\r\nprocess can connect successfully to the pipe connection created by the second process, it resets the environment\r\nvariables ‘svch’ and ‘ppid’ to 0.\r\nProcess 2 (core routine)\r\nWhen the bot is run in another process, it sets the environment variable ‘svch’ to 0. A thread is created that creates a\r\nnamed pipe. If a connection is established, the thread reads the bytes that are written from the other process. If the\r\nmessage is ‘kill’ xor’ed by VolumeSerialNumber, the process terminates. However, if the message is ‘gpid’, then it\r\nsends its current process ID to the first process. This information is used by the old process to access information about\r\nthe new process when the new process terminates. When the new process terminates, the old process checks the handle\r\nof the process. If the message is ‘kill’ xor’ed by VolumeSerialNumber, then the old process terminates. This check is\r\nmade when the bot wants to update itself and hence has to make sure that the watchdog threads have been terminated.\r\nOtherwise, the old process terminates the new process and runs the file in %alluserprofile% again.\r\nAfter the new process has created its thread to connect to the C\u0026C server, it will get the ‘ppid’ environment variable.\r\nThis variable contains the process ID of the old process. Like the old process, it uses this information to access when the\r\nold process terminates. And if the message is ‘kill’ xor’ed by VolumeSerialNumber, then the new process terminates.\r\nThis check is performed when an installation is taking place. Otherwise, the new process runs the file in\r\n%alluserprofile% and terminates itself.\r\nFigure 11 shows how the process IDs are used by the processes.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 9 of 14\n\nFigure 11. Process IDs used by the processes.\r\nThe second thread created by the new process carries out some further code injection. It first resolves winhttp.dll APIs\r\nusing the anti-API hooking technique and also inline hooks three APIs: ws2_32.GetAddrInfoW (Figure 12 and Figure\r\n13), ntdll.ZwMapViewOfSection and ntdll.ZwUnmapViewOfSection. The control flow of the APIs is redirected by\r\ninserting a jump to the malicious function. Before writing to the API, it calls VirtualProtect. After the bytes have been\r\nwritten, it calls FlushInstructionCache so that the changes take effect immediately.\r\nFigure 12. Before inline hooking GetAddrInfoW.\r\nFigure 13. After inline hooking GetAddrInfoW.\r\nIt then calls QueueUserAPC, which creates an asynchronous procedure call object. This object points to the code which\r\ndecrypts some encrypted strings using RC4 decryption (Figure 14). These encrypted strings are the domains it intends to\r\nconnect to. Before each decrypted string, it inserts the DWORD 0x6C727501 xor’ed by VolumeSerialNumber, which is\r\nASCII for URL. This magic DWORD is used when it calls the RtlWalkHeap API to retrieve the domain names from the\r\nheap.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 10 of 14\n\nFigure 14. The decrypted domain names (now offline).\r\nCommunication protocol, encryption algorithm\r\nCreate connections\r\nThe hooked GetAddrInfoW API performs a DNS query for the input host name from Google DNS server 8.8.4.4 (Figure\r\n15) using a randomly generated query identifier. It then returns the query result or ‘127.0.0.1’ if the DNS query fails.\r\nThe DNS record received is then used for querying the C\u0026C domain name. It does this to avoid any application level\r\nDNS server redirection. The hooked ZwMapViewOfSection and ZwUnmapViewOfSection APIs will be used later to\r\nmap/unmap the plug in image downloaded from the C\u0026C server.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 11 of 14\n\nFigure 15. Hard-coded Google DNS server IP in the GetAddrInfoW hooked function.\r\nCommunication protocol and encryption algorithm\r\nBefore establishing a connection, the bot prepares the message to be sent to the C\u0026C server. It uses the following\r\nformat:\r\nid:%lu|bid:%lu|bv:%lu|os:%lu|la:%lu|rg:%lu\r\nid is the VolumeSerialNumber, which is used as an RC4 key to decrypt the message received\r\nbid is a hard coded DWORD used for the communication\r\nbv is the version of the botnet (in this case it is 2.7)\r\nos is the version of the current operating system\r\nla is the socket name byte swapped\r\nrg is set to 1 if the process is in the Administrator group, otherwise it is 0 (Figure 16).\r\nThis string is encrypted using RC4 with a hard-coded key of length 0x20 and is further encrypted using base64. The\r\nmessage is then sent to the server. Once a message is received, the bot calculates the CRC32 hash of the message\r\nwithout including the first DWORD (Figure 16). If the calculated hash matches the first DWORD, the message is valid.\r\nLater it is decrypted using RC4 with the VolumeSerialNumber as the key. After the RC4 decryption the message is in\r\nthe format gn([base64-encoded string]). This used to be just the base64 encoded string, but for some reason the author\r\ndecided not to make the server backward compatible with the older bot versions. Then it decodes the base64 string\r\ninside the brackets to get the message in plain text (Figure 17).\r\nFigure 16. First DWORD of message received containing the CRC32 hash value.\r\nFigure 17. Message received from the server.\r\nThe first DWORD of the message is used as a multiplier to multiply a value in a fixed offset. The DWORD in that offset\r\nis used as an interval to delay calling the thread again to establish another connection. The next byte indicates what\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 12 of 14\n\naction to carry out – there are seven options:\r\nCase 1 (download EXE):\r\nConnect to the domain decrypted from the message to download an EXE file. Save the file to the %tmp%\r\nlocation with a random name and run the process.\r\nCase 2 (load plug-ins):\r\nConnect to the domain decrypted from the message, install and load plug ins. The plug ins are decrypted by RC4\r\nusing the same key of length 0x20h.\r\nCase 3 (update case):\r\nConnect to the domain to get the update EXE file. If a filename of VolumeSerialNumber is present in the registry,\r\nthen save the PE file to the %tmp% location with a random name; else save it to the current location with the\r\nname of the file as VolumeSerialNumber. The file in %tmp% is run, while the current process terminates. It also\r\nsends the message ‘kill’ xor’ed by VolumeSerialNumber to terminate the older process.\r\nCase 4 (download DLL):\r\nConnect to the domain and save the DLL file to the %alluserprofile% location. The file is saved as a .dat file with\r\na random name and loaded from a specified export function. The registry is modified so it can be auto-loaded by\r\nthe bot.\r\nCase 5 (delete DLLs):\r\nDelete and uninstall all the DLLs loaded and installed in Case 4.\r\nCase 6 (delete plug-ins):\r\nUninstall all the plug-ins loaded in Case 3.\r\nCase 7 (uninstall bot):\r\nSuspend all threads and uninstall the bot.\r\nAfter executing the action based on which instruction it received, another message is sent to the server to notify it that\r\nthe action has been completed:\r\nid:%lu|tid:%lu|res:%lu\r\nid is the VolumeSerialNumber\r\ntid is the next byte (task id) after the byte displaying the case number in the message received\r\nres is the result of whether or not the task was carried out successfully.\r\nOnce the message has been sent, the thread exits and waits for the delay interval period to pass before it reconnects to\r\nthe server to receive additional instructions.\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 13 of 14\n\nConclusion\r\nThis new version of the Andromeda bot has demonstrated its tenacity by executing code that ensures every instance of\r\nits process is kept running and by employing more anti debug/anti VM tricks than its previous version. However, it is\r\nstill possible to bypass all those tricks once we have complete knowledge of its executing procedures. Moreover, we\r\ncould easily block its communication data after addressing the decryption performance issue.\r\nBibliography\r\n[1] All the environment variables used in this version of Andromeda are encrypted using xor on the\r\nVolumeSerialNumber, which the file acquires by calling GetVolumeInformationA on drive C:\\. The bot employs this\r\ntechnique as a way of specifying its status in the machine. ‘svch’ is a flag if the process is injected into svchost.exe; ‘src’\r\nstores the location of the file; ‘ppid’ stores the first process ID;‘gpid’ stores the second process ID.\r\n[2] Tan, N. Andromeda Botnet. Virus Bulletin, June 2012, pp.5–11.\r\nSource: https://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nhttps://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2013/08/andromeda-2-7-features"
	],
	"report_names": [
		"andromeda-2-7-features"
	],
	"threat_actors": [
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434329,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bd9ed4cee54d672a809a865a40d67ec167b2acf6.pdf",
		"text": "https://archive.orkl.eu/bd9ed4cee54d672a809a865a40d67ec167b2acf6.txt",
		"img": "https://archive.orkl.eu/bd9ed4cee54d672a809a865a40d67ec167b2acf6.jpg"
	}
}