{
	"id": "b315676f-68b9-4c0a-9ef9-2dda1255c51c",
	"created_at": "2026-04-06T00:13:07.529556Z",
	"updated_at": "2026-04-10T13:12:48.322608Z",
	"deleted_at": null,
	"sha1_hash": "69da93358b078f82fdd678f6f9dbcefdf31d3347",
	"title": "REKOOBE APT-31 Linux Backdoor Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2082053,
	"plain_text": "REKOOBE APT-31 Linux Backdoor Analysis\r\nBy techevo\r\nPublished: 2024-11-30 · Archived: 2026-04-05 21:40:05 UTC\r\nIn this post I will be taking a look at a Linux backdoor known as REKOOBE1\r\nReporting suggests this and previous iterations have been used by APT-31 against a variety of victims.\r\nThis post will go over both static and dynamic analysis techniques, as well as provide some primitive scripts to\r\nautomate extracting the C2 details.\r\nThe sample for this analysis can be found here and here with the SHA1:\r\n23e0c1854c1a90e94cd1c427c201ecf879b2fa78 .\r\nAs with previous posts, it might be beneficial to follow along, and hopefully the post is structured in a way that\r\nmakes that possible.\r\nOutput from commands and scripts used for this post can be found in this Github repository.\r\nStatic Analysis\r\nThe start of any analysis should be to verify what it is that needs analyzing.\r\nUsing the file\r\n2\r\n command, the output shows the target file is a dynamically linked 64-bit ELF executable.\r\nThis is a hopeful start as any imported functions should be visible to us, unless the sample is packed.\r\nfile rekoobe.elf\r\nrekoobe.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,\r\n interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18,\r\n BuildID[sha1]=025ab2845d244964abc35fb2cffadf388408fa14, stripped\r\nOne additional take-away from the file output is the “GNU/Linux” version that is referenced: 2.6.18 .\r\nWhilst compiling code on modern compilers will generally result in older versions being targeted for\r\ncompatibility reasons, this version is well beyond expected values.\r\nThere are at least two reasons for this:\r\n1) The binary was compiled on a very old Linux system.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 1 of 15\n\n2) The binary is designed to be deployed on potentially very old Linux systems.\r\nFor reference, version 2.6.10 of the Linux kernel was released in 20063\r\nThe output of the strings command also hints this sample was compiled using a version of GCC from 20124.\r\nstrings rekoobe.elf\r\n...\r\nGCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-4)\r\n...\r\nBefore wading into the depths of functions, reviewing the required shared libraries shows that anything imported\r\nis pretty standard. No additional functionality in custom shared libraries as is sometimes the case with Windows\r\nmalware.\r\nreadelf -d rekoobe.elf\r\nDynamic section at offset 0x14028 contains 23 entries:\r\n Tag Type Name/Value\r\n 0x0000000000000001 (NEEDED) Shared library: [libutil.so.1]\r\n 0x0000000000000001 (NEEDED) Shared library: [librt.so.1]\r\n 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]\r\n 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]\r\n...\r\nI have radare25 installed so will be making use of various tools from the framework. You do not have to use the\r\nsame tools, any tools for interrogating ELF files should work fine.\r\nUsing rabin2 to list the imports, shows that this sample makes use of the execv function, which allows\r\nexecution of arbitrary system commands.\r\nThe output below is truncated, the full output can be viewed here.\r\nIn addition to execv , the output also showed execl , recv , setsockopt , bind , and openpty , which all\r\nseem a little suspicious. These functions resemble the basis for a backdoor, and certainly should raise some\r\neyebrows.\r\nrabin2 -i rekoobe.elf\r\n[Imports]\r\nnth vaddr bind type lib name\r\n―――――――――――――――――――――――――――――――――――――\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 2 of 15\n\n1 0x00401790 GLOBAL FUNC daemon\r\n2 0x004017a0 GLOBAL FUNC chmod\r\n3 0x004017b0 GLOBAL FUNC dup2\r\n4 0x004017c0 GLOBAL FUNC execv\r\n5 0x004017d0 GLOBAL FUNC memset\r\n6 0x004017e0 GLOBAL FUNC setsid\r\n7 0x004017f0 GLOBAL FUNC shutdown\r\n...\r\nYou shouldn’t take my word for it either!\r\nRather than going through every imported function and reading the documentation, Capa6 provides a nice way to\r\nscan for functionality of binaries.\r\n./capa ./rekoobe.elf\r\nFigure 1: Capa output for Rekoobe sample.\r\nThe output in Figure 1 shows Remote Access::Reverse Shell, which pretty much sums it up, case closed.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 3 of 15\n\nThe Capa output shows that there are references to RC4 and AES encryption routines, which might be interesting\r\nto take a look into. The full output from Capa can be found here.\r\nLet’s start exploring the binary in a disassembler.\r\nThe main symbol is exported so should be quickly identifiable in other tools such as Ghidra7 or IDA.\r\nThe following command will print dissasembly located at the main function.\r\nr2 -AA -q -c 'pdf @ main;' rekoobe.elf\r\nFigure 2: Radare2 main routine.\r\nThe output shows that the process first calls the imported symbol daemon , allowing the execution to continue in\r\nthe background. A function labeled fcn.00404568 is called, and the return value in EAX is checked before\r\ncalling another function labeled fcn.00404415 .\r\nStatic Analysis: fcn.00404568\r\nStarting with fcn.00404568 the command below prints the first 27 instructions of the function. Why 27? Because\r\nit looked nice in the screen shot.\r\nr2 -AA -q -c 'pd 27 @ fcn.00404568' rekoobe.elf\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 4 of 15\n\nFigure 3: Radare2 fcn.00404568 disassembly.\r\nStarting at 0x0040459c , there is a sequence of 8 mov byte instructions. The 8 bytes are ASCII characters\r\ndepicted as shown:\r\nThe \\0 (NULL) byte terminates the character array.\r\n0x72 = r\r\n0x30 = 0\r\n0x73 = s\r\n0x74 = t\r\n0x40 = @\r\n0x23 = #\r\n0x24 = $\r\n0x00 = '\\0'\r\nFollowing the mov byte instructions there is then a value comparison with a byte located at 0x00614740 located\r\nin the .data section of the ELF file.\r\nIf the value is set to 0 , then the je , jumps to the end of the function before returning.\r\nThis value turns out to be quite important later on…\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 5 of 15\n\nThe Capa output told us there was stack strings in use, and this is one of them. At this stage it is not important\r\nwhat this string is used for, however if there are more, it would be nice to recover them.\r\nI created a script to recover these strings, which you can view here The output shown is truncated. A copy of the\r\nfull output can be viewed here\r\npython3 ./recover_stack_strings.py ./rekoobe.elf\r\n%02x\r\n%02X\r\nr0st@#$\r\n/etc//etc/issue.net\r\n/etc/issue\r\n/proc/ve/etc/issue.net\r\n/etc/issue\r\n/proc/version\r\nr.\r\n/\r\n.\r\n/\r\n%s/%s\r\n.\r\n..\r\nrb\r\na+b\r\na+b\r\n/usr/usr/include/sdfwex.h\r\n/tmp/.l\r\n...\r\nWhilst the output is far from perfect and not production ready, you can see it located the r0st@#$ string\r\ncorrectly, as well as some interesting file paths.\r\nContinuing on, a WORD (2 bytes) is read from 0x00614741 into EDX with the value of 12 .\r\nFigure 4: Radare2 size parameter read.\r\nZooming out, shows the use of this parameter more clearly.\r\nA memory address 0x614743 is stored into ESI , before both are passed into memcpy , to copy 12 bytes from the\r\nlocation stored in ESI into a buffer labeled s1 .\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 6 of 15\n\nAfter the memcpy function returns the stack string we recovered earlier located at [var_1860h] , the value 12\r\nand the address of the s1 buffer as passed to a function called fcn.00402af9 .\r\nFigure 5: Radare2 string operations.\r\nStatic Analysis: fcn.00402af9\r\nThe functionality of fcn.00402af9 is an implementation of the RC48 cipher.\r\nThe parameters passed to fcn.00402af9 , are shown in the function prototype.\r\nvoid fcn.00402af9(\r\n char *buffer,\r\n int64_t length,\r\n char *key\r\n)\r\nThe buffer contains the ciphered data on input, and on output contains the original clear-text data.\r\nThe length contains the length of the data stored in the buffer, as \\0 (NULL) bytes will not be used to terminate\r\nthe data.\r\nFinally, the key , in this call is the r0st@#$ string.\r\nWe can quickly test this out taking the various inputs and using the RC4 CyberChef recipe.\r\nFirst extract the 12 input bytes from 0x614743.\r\nr2 -AA -q -c 'px0 12 @ 0x614743' rekoobe.elf\r\n553c5fffec8a52c936c8d902\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 7 of 15\n\nFigure 6: CyberChef RC4\r\nAs the RC4 code was its own function, we can find cross-references to this routine to locate more values being\r\ndecrypted that might be useful in later analysis.\r\nThe axt command shows there are 10 calls to this RC4 function, which are worthy of further exploration.\r\nr2 -AA -q -c 'axt @ 0x00402af9;' rekoobe.elf\r\nfcn.0040225c 0x4022d3 [CALL:--x] call fcn.00402af9\r\nfcn.00404568 0x40461f [CALL:--x] call fcn.00402af9\r\nfcn.00404b27 0x404dc8 [CALL:--x] call fcn.00402af9\r\nfcn.00404b27 0x404ea4 [CALL:--x] call fcn.00402af9\r\nfcn.00404f06 0x405130 [CALL:--x] call fcn.00402af9\r\nfcn.00404f06 0x40525d [CALL:--x] call fcn.00402af9\r\nfcn.0040ba91 0x40bad4 [CALL:--x] call fcn.00402af9\r\nfcn.0040ba91 0x40bb10 [CALL:--x] call fcn.00402af9\r\nfcn.0040bbe3 0x40bc5e [CALL:--x] call fcn.00402af9\r\nfcn.0040bbe3 0x40bcf2 [CALL:--x] call fcn.00402af9\r\nStatic Analysis: fcn.00404568 (continued)\r\nReturning (pun intended) back to fcn.00404568 , we now have a decrypted string:\r\n/usr/bin/ssh\r\nFigure 6 shows a call to strcpy ( 0x0040467f ), which shows the value stored in RBP moved into RSI as the\r\nsource of the string copy operation. The screen shot shows that RBP contains the buffer address used to decrypt\r\nthe string using the RC4 decryption routine.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 8 of 15\n\nFigure 6: Radare2 string operations.\r\nUsing the Ghidra plugin9 for Radare2 with the command pdga , Figure 7 shows the destination more clearly, as\r\n*param_1 .\r\nFigure 7: Radare2 Ghidra disassemble .\r\nGoing back to see what was passed into this function shown in Figure 8, we see from main that argv is the\r\nonly parameter supplied ( 0x00404971 ).\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 9 of 15\n\nFigure 8: Radare2 call fcn.00404568 .\r\nOverwriting argv will for all intents and purposes alter the process name, allowing the process to avoid\r\ndetection. When executed, this process will appear to be named /usr/bin/ssh , when commands such as ps\r\nand top are used to inspect the system.\r\nThis function contains more capabilities to copy and rename itself based on the value that is checked, however in\r\nthis sample, it returns to main setting the return code to 1 which allows execution to continue into\r\nfcn.00404415 shown in Figure 8.\r\nStatic Analysis: fcn.0040225c\r\nFrom the main function, fcn.00404415 is called which performs some value checks before calling\r\nfcn.0040225c .\r\nThe start of the function builds the same stack string r0st@#$ as previously seen, and calls the same RC4\r\nwrapper. The input length is stored at 0x6144e0 and contains decimal 42.\r\nThe 42 bytes of input is located at 0x6144e2 , again in the .data section.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 10 of 15\n\nFigure 9: Radare2 decrypt configuration.\r\nThe following command will extract the hexadecimal stream to be decrypted.\r\nr2 -AA -q -c 'px0 42 @ 0x6144e2' rekoobe.elf\r\n42671ebcfbc60295378a98593b13a7e9721f03aac47781891b5f10926882a5239c6d961129b3d32ca620\r\nUsing the same CyberChef recipe as before, it shows an IPv4 address and port, as well as some binary flag values.\r\nFigure 10: CyberChef decrypt configuration.\r\nThere are 4 sections in this configuration, delimited by | values. These sections are identified using the strstr\r\nfunction by the malware.\r\nConfigurations options are then further split using ; , before being parsed using strtol to convert the string\r\nvalues “1” to a long integer.\r\nStatic Analysis: fcn.00401db4\r\nBefore heading into some dynamic analysis, I thought it was worth highlighting the function fcn.00401db4 .\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 11 of 15\n\nThe script to recover the stack strings highlighted some interesting file paths common on Linux systems. This\r\nfunction is where they reside and it responsible for collecting information regarding the infected system.\r\nThe stack strings, reveal the following file paths:\r\n/etc/issue.net\r\n/etc/issue\r\n/proc/version\r\nFirst /etc/issue.net is passed to fopen and if that fails then /etc/issue is opened. The procfs file\r\n/proc/version is opened and strstr us used to locate the value x86_64 , which determines the host\r\narchitecture.\r\nA call to gethostname is fairly self explanatory, gathering the hostname.\r\nA call to getifaddrs returns a structure containing a linked-list, which is traversed gathering the IP address from\r\neach network interface.\r\nDynamic Analysis\r\nFrom the static analysis, the command and control IPv4 was determined. Unfortunately at the time of analysis no\r\nresponse on the provided port was returned.\r\nTo see how the sample would have interacted with the server, we need to provide a route to the IP address:\r\n8.218.92[.]123 .\r\nThis can be achieved using the lo loopback interface as shown.\r\nsudo ip addr add 8.218.92[.]123 dev lo\r\nOnce the IP address has been added, a nc netcat listener can be setup on the required port.\r\nnc -l -p 9987 \u003e output.bin\r\nUsing the ltrace\r\n10\r\n program, it is possible to trace the library calls of this dynamically linked executable, saving\r\nthe output into the ltrace.out file. A copy of the full output can be found here\r\nltrace -fbS -o ltrace.out ./rekoobe.elf\r\nFigure 11 shows the output of ltrace revealing the configuration strings.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 12 of 15\n\nFigure 11: ltrace decrypt configuration.\r\nFigure 12 shows the various files being opened to gather information regarding the host. It also shows a call to the\r\nsocket and bind functions, indicating a listing port being established.\r\nFigure 12: ltrace decrypt configuration.\r\nThe dynamic analysis confirms the findings from the static analysis.\r\nIn a slightly modified lab setup, I was able to capture the network communications between the malware and the\r\nC2 server.\r\nThe PCAP file is available here, and shows that 548 bytes were sent over the TCP socket. The data in both\r\ndirections is binary data, rather than encapsulated in HTTP.\r\nFrom the analysis performed, both the process name and configuration string were stored in the .data section.\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 13 of 15\n\nUsing radare2 , locating the .data virtual address, and printing the hexdump shows the encrypted strings.\r\niS~.data\r\ns 0x006144c0\r\npxs 810\r\nFigure 13: Radare2 .data section hex dump.\r\nUsing this information, I have developed a configuration extractor which can be found here\r\nExecuting the script, and providing the RC4 key outputs JSON document containing the C2 details.\r\npython3 ./rekoobe_config.py rekoobe.elf r0st@#$\r\n{\r\n \"c2\": \"8.218.92.123:9987\",\r\n \"flags\": {\r\n \"unknown_0\": 1,\r\n \"unknown_1\": 1,\r\n \"unknown_2\": 1,\r\n \"unknown_3\": 1,\r\n \"unknown_4\": 1,\r\n \"unknown_5\": 1,\r\n \"unknown_6\": 1\r\n },\r\n \"hours\": \"00-24\",\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 14 of 15\n\n\"process_change\": 1,\r\n \"process_name\": \"/usr/bin/ssh\",\r\n \"unknown\": 1\r\n}\r\nConclusion\r\nIn this post we have explored the initial workings of the REKOOBE backdoor, identifying how the command and\r\ncontrol details are retrieved and shown a Python script to extract the details.\r\nThere is more to this sample, however the internals of this backdoor have been researched in prior work. Some\r\nnotable research from AhnLab and hunt.io among others.\r\nIf you enjoyed reading or learnt something new, let me know!\r\nYou can find me on Twitter (currently known as X) as well as BlueSky.\r\nUntil next time, keep evolving.\r\ntechevo\r\nReferences\r\n1. https://malpedia.caad.fkie.fraunhofer.de/details/elf.rekoobe ↩\r\n2. https://linux.die.net/man/1/file ↩\r\n3. https://kernelnewbies.org/Linux_2_6_18 ↩\r\n4. https://gcc.gnu.org/gcc-4.4/ ↩\r\n5. https://rada.re/n/ ↩\r\n6. https://linux.die.net/man/3/execv ↩\r\n7. https://github.com/mandiant/capa ↩\r\n8. https://en.wikipedia.org/wiki/RC4 ↩\r\n9. https://github.com/radareorg/r2ghidra ↩\r\n10. https://man7.org/linux/man-pages/man1/ltrace.1.html ↩\r\nSource: https://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nhttps://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.techevo.uk/analysis/linux/2024/11/30/rekoobe-apt31-linux-backdoor.html"
	],
	"report_names": [
		"rekoobe-apt31-linux-backdoor.html"
	],
	"threat_actors": [
		{
			"id": "1f6ae238-765f-4495-9d54-6a7883d7a319",
			"created_at": "2022-10-25T16:07:24.573456Z",
			"updated_at": "2026-04-10T02:00:05.037738Z",
			"deleted_at": null,
			"main_name": "TA511",
			"aliases": [
				"MAN1",
				"Moskalvzapoe"
			],
			"source_name": "ETDA:TA511",
			"tools": [
				"Agentemis",
				"Chanitor",
				"Cobalt Strike",
				"CobaltStrike",
				"Ficker Stealer",
				"Hancitor",
				"NetSupport",
				"NetSupport Manager",
				"NetSupport Manager RAT",
				"NetSupport RAT",
				"NetSupportManager RAT",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "aacd5cbc-604b-4b6e-9e58-ef96c5d1a784",
			"created_at": "2023-01-06T13:46:38.953463Z",
			"updated_at": "2026-04-10T02:00:03.159523Z",
			"deleted_at": null,
			"main_name": "APT31",
			"aliases": [
				"JUDGMENT PANDA",
				"BRONZE VINEWOOD",
				"Red keres",
				"Violet Typhoon",
				"TA412"
			],
			"source_name": "MISPGALAXY:APT31",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "9e6186dd-9334-4aac-9957-98f022cd3871",
			"created_at": "2022-10-25T15:50:23.357398Z",
			"updated_at": "2026-04-10T02:00:05.368552Z",
			"deleted_at": null,
			"main_name": "ZIRCONIUM",
			"aliases": [
				"APT31",
				"Violet Typhoon"
			],
			"source_name": "MITRE:ZIRCONIUM",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "542cf9d0-9c68-428c-aff8-81b6f59dc985",
			"created_at": "2023-02-15T02:01:49.554105Z",
			"updated_at": "2026-04-10T02:00:03.347115Z",
			"deleted_at": null,
			"main_name": "Moskalvzapoe",
			"aliases": [
				"MAN1",
				"TA511"
			],
			"source_name": "MISPGALAXY:Moskalvzapoe",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "74d9dada-0106-414a-8bb9-b0d527db7756",
			"created_at": "2025-08-07T02:03:24.69718Z",
			"updated_at": "2026-04-10T02:00:03.733346Z",
			"deleted_at": null,
			"main_name": "BRONZE VINEWOOD",
			"aliases": [
				"APT31 ",
				"BRONZE EXPRESS ",
				"Judgment Panda ",
				"Red Keres",
				"TA412",
				"VINEWOOD ",
				"Violet Typhoon ",
				"ZIRCONIUM "
			],
			"source_name": "Secureworks:BRONZE VINEWOOD",
			"tools": [
				"DropboxAES RAT",
				"HanaLoader",
				"Metasploit",
				"Mimikatz",
				"Reverse ICMP shell",
				"Trochilus"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "dc7ee503-9494-4fb6-a678-440c68fd31d8",
			"created_at": "2022-10-25T16:07:23.349177Z",
			"updated_at": "2026-04-10T02:00:04.552639Z",
			"deleted_at": null,
			"main_name": "APT 31",
			"aliases": [
				"APT 31",
				"Bronze Vinewood",
				"G0128",
				"Judgment Panda",
				"Red Keres",
				"RedBravo",
				"TA412",
				"Violet Typhoon",
				"Zirconium"
			],
			"source_name": "ETDA:APT 31",
			"tools": [
				"9002 RAT",
				"Agent.dhwf",
				"AngryRebel",
				"CHINACHOPPER",
				"China Chopper",
				"Destroy RAT",
				"DestroyRAT",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"GrewApacha",
				"HOMEUNIX",
				"HiKit",
				"HidraQ",
				"Homux",
				"Hydraq",
				"Kaba",
				"Korplug",
				"McRAT",
				"MdmBot",
				"Moudour",
				"Mydoor",
				"PCRat",
				"PlugX",
				"RedDelta",
				"Roarur",
				"Sakula",
				"Sakula RAT",
				"Sakurel",
				"SinoChopper",
				"Sogu",
				"TIGERPLUG",
				"TVT",
				"Thoper",
				"Trochilus RAT",
				"Xamtrav"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434387,
	"ts_updated_at": 1775826768,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/69da93358b078f82fdd678f6f9dbcefdf31d3347.pdf",
		"text": "https://archive.orkl.eu/69da93358b078f82fdd678f6f9dbcefdf31d3347.txt",
		"img": "https://archive.orkl.eu/69da93358b078f82fdd678f6f9dbcefdf31d3347.jpg"
	}
}