{
	"id": "e4aa0818-1bec-472a-9c1d-f1c63dc35d67",
	"created_at": "2026-04-06T00:18:07.815108Z",
	"updated_at": "2026-04-10T03:24:18.239539Z",
	"deleted_at": null,
	"sha1_hash": "590d6486d3f9bf48e1005ce46f8ae6433bf7bc49",
	"title": "Auto-color - Linux backdoor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 578311,
	"plain_text": "Auto-color - Linux backdoor\r\nBy Mohamed Ezzat\r\nPublished: 2025-03-28 · Archived: 2026-04-05 22:58:47 UTC\r\n17 minute read\r\nMeet Auto-colorPermalink\r\nAuto-color is a Linux backdoor that has been seen in cyberattacks targeting government organizations and\r\nuniversities in North America and Asia. It was first observed between November and December 2024 and is\r\ndesigned to avoid detection while remaining hidden in systems for a long time. The malware acts as be benign\r\ncolor-enhancement tool and uses common file names like “door,” “egg,” and “log” to disguise itself.\r\nAuto-color gets its name from the file name that the initial payload uses to rename itself after it is installed.\r\nTechnical in PointsPermalink\r\nAuto-Color encrypts its strings to prevent easy extraction of its functionality. Additionally, it dynamically\r\nresolves APIs at runtime, loading libc and retrieving function addresses with dlsym. This makes static\r\ndetection harder by avoiding direct system calls.\r\nAuto-Color uses multiple evasion techniques to avoid detection. It hides itself with a benign name merged\r\nwith system files and operates as a background process without user interaction. If executed with root\r\nprivileges, more advanced tactics are used. Dropping a shared library that hooks libc functions to hide\r\nnetwork connections, stop uninstallation, and ensure its activities remain undetected.\r\nAuto-Color’s data section contains an embedded custom encrypted configuration, including information\r\nabout its Command-and-Control (C2) server. It then sets a communication channel with the C2 server\r\nusing a TCP socket and validates the exchange via a random value handshake.\r\nAuto-Color receives remote commands to execute on the infected machine, including gathering system and\r\nhost information, reading, writing, deleting, and modifying files, creating a reverse shell backdoor,\r\nconfiguring the device as a proxy, and self-destructing to erase all traces of its presence. This gives the\r\nattacker full control over the compromised system.\r\nFirst lookPermalink\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 1 of 19\n\nFigure(1): Sample on VT\r\nThe sample is a C/C++ ELF64 binary compiled for Ubuntu Linux. On the writing date, only 15 security\r\nvendors flagged it as malicious.\r\nAuto-color seems to require explicit execution by the victim and follows two main paths based on root privileges.\r\nFigure(2): Main function\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 2 of 19\n\nIf running as root, it checks its execution path against the target path /var/log/cross/auto-color to determine if\r\nit has already been installed and executed before. If not, it tries to install itself and prints “install ok” if successful.\r\nIf it is not running as root or the path check fails, it follows another path called “green mode.”\r\nRegardless of the path taken, Auto-color daemonizes itself to run in the background before connecting to a\r\ncommand-and-control (C2) server for further instructions.\r\nString DecryptionPermalink\r\nAuto-color obfuscated its strings using an XOR operation and additional arithmetic transformations to make\r\nanalysis more difficult.\r\nFigure(3): Sring decryption function\r\nThe decryption function always follows the same instruction sequence:\r\nlea rsi, enc_str_ptr\r\nmov rdi, rax\r\ncall mw_string_decryption\r\nWe can use this pattern to write an IDAPython script that automatically finds and decrypts obfuscated strings,\r\nmaking analysis easier.\r\nimport idautils\r\nimport idc\r\nimport idaapi\r\ndef decrypt_string(enc_data):\r\n res = []\r\n for byte in enc_data:\r\n dec_byte = ((int(byte) + 123) ^ 0x1F) - 123 \u0026 0xFF\r\n if dec_byte == 0:\r\n break\r\n res.append(dec_byte)\r\n return bytes(res).decode('utf-8', errors='replace')\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 3 of 19\n\ndef read_enc_data(ptr):\r\n # read memory until a null byte\r\n address = idc.get_name_ea_simple(ptr)\r\n if address == idc.BADADDR:\r\n return None\r\n \r\n data = []\r\n while (byte := ida_bytes.get_byte(address)) != 0:\r\n data.append(byte)\r\n address += 1\r\n return bytes(data)\r\ndef find_decryption_function_xrefs():\r\n # (i + a2) + 123) ^ 0x1F) - 123\r\n pattern = \"0F B6 00 83 C0 7B 83 F0 1F 83 E8 7B 89 C2 8B 85 ?? ?? ?? ??\"\r\n ea = idaapi.find_binary(0, idc.BADADDR, pattern, 16, idc.SEARCH_DOWN)\r\n if ea == idc.BADADDR:\r\n return []\r\n \r\n func_ea = idc.get_func_attr(ea, idc.FUNCATTR_START)\r\n if func_ea == idc.BADADDR:\r\n return []\r\n return list(idautils.CodeRefsTo(func_ea, 0))\r\ndef set_hexrays_comment(address, text):\r\n cfunc = idaapi.decompile(address)\r\n tl = idaapi.treeloc_t()\r\n tl.ea = address\r\n tl.itp = idaapi.ITP_SEMI\r\n cfunc.set_user_cmt(tl, text)\r\n cfunc.save_user_cmts()\r\ndef main():\r\n xrefs = find_decryption_function_xrefs()\r\n for ref in xrefs:\r\n prev_ins_addr = idc.prev_head(ref)\r\n prev_ins_addr = idc.prev_head(prev_ins_addr) # go up twice\r\n if (idc.print_insn_mnem(prev_ins_addr) == 'lea' and\r\n idc.print_operand(prev_ins_addr, 0) == 'rsi'):\r\n ind = idc.print_operand(prev_ins_addr, 1)\r\n enc_data = read_enc_data(ind)\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 4 of 19\n\ndec_str = decrypt_string(enc_data)\r\n idc.set_cmt(ref, f\"String : {dec_str}\", 0)\r\n set_hexrays_comment(ref,f\"String: {dec_str}\")\r\nif __name__ == \"__main__\":\r\n main()\r\nThis script finds the decryption function by searching for its instruction pattern, determines all cross-references to\r\nthe function and locates the lea instruction that loads the encrypted string. It then reads the bytes, decrypts\r\nthem, and finally adds comments in both the disassembly and decompiled views.\r\nfull strings list\r\nExpand to see more\r\n  config-err-\r\n  %d\r\n  %x\r\n  /var/log/cross\r\nMalware InstallationPermalink\r\nAuto-color first creates a directory /var/log/cross to mix in with system logs and avoid suspicion. It sets 777\r\npermissions, allowing it to read, write, or execute files inside. Then, it copies itself into this folder and renames its\r\nfile to “auto-color” to appear benign.\r\nIt also drops a malicious shared library named libcext.so.2 into the system’s library path. This library mimics\r\nthe legitimate libcext.so.0 to avoid suspicion. Auto-color dynamically resolves the system’s standard library\r\ndirectory using the dladdr() function with the strerror() symbol. If successful, it extracts the directory path\r\nfrom info.dli_fname, removes the filename, and constructs the final path. If dladdr() fails, it defaults to /lib\r\nas the base directory, to Make sure it works on various Linux versions.\r\nIt finally modifies the /etc/ld.preload , a Linux file that forces specified libraries to load into every process .\r\nBy adding libcext.so.2 to this file, it ensures its library is loaded even before legitimate system libraries.\r\nThis enables it to hook and override critical functions , which I will explain later in the blog.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 5 of 19\n\nFigure(4): Malware Installation function\r\nIt also unlinks (deletes) any previous executable and malicious shared library to remove traces of old installations.\r\nThis avoids conflicts and ensures a clean setup.\r\nRunning in the Background - DemonstrationPermalink\r\nAuto-color ensures that only one instance runs by using a file-based locking mechanism. It creates a lock file in\r\n/tmp based on the user’s ID, opens it, and tries to lock it using flock() . If another instance has already locked\r\nthe file, it exits to prevent multiple copies from running.\r\nFigure(5): file-based locking mechanism used\r\nAuto-color then daemonizes itself, following a famous technique to run in the background without a controlling\r\nterminal. It first creates a child process and exits the parent, then calls setsid() to start a new session and fully\r\nseparate from the terminal. A second fork is used to stop the process from accidentally retrieving a terminal\r\nconnection.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 6 of 19\n\nFigure(6): Demonstration function\r\nTo complete the process, Auto-color shifts input, output, and error to /dev/null to control unwanted\r\ninteractions. It also closes all open file descriptors, removes file permission restrictions with umask(0) , and\r\nchanges its working directory to / to avoid issues with folders.\r\nThese steps ensure the malware runs smoothly in the background, making it harder to detect and stop.\r\nAuto-color ’s C2 FunctionalityPermalink\r\nBefore connecting to its C2 servers, Auto-color first extracts the C2 address from an encrypted configuration.\r\nAuto-color contains an embedded custom encrypted configuration within its .data section.\r\nFigure(7): Encrypted config .\r\nThis decryption algorithm uses a key-based transformation, where the key is extracted from the last four bytes of\r\nthe encrypted data. The key is dynamically updated at each step using a mathematical formula. Each byte of the\r\ndata is modified through bit shifts, subtraction, and XOR operations.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 7 of 19\n\nFigure(8): Custom decryption algorithm used .\r\nHere is the Python version of the decryption function:\r\ndef decryption_algo(key, enc_data):\r\n dec_data = bytearray(len(enc_data))\r\n \r\n for i in range(len(dec_data)):\r\n key = (1023 * key - 0x70E52827) \u0026 0xFFFFFFFF\r\n dec_data[i] = ((enc_data[i] - (key \u003e\u003e 19)) ^ (key \u003e\u003e 11)) - (key \u003e\u003e 3) \u0026 0xFF\r\n \r\n return dec_data\r\nhex_input = \"5B742B73F5A211A1FB87436A463AE1BBF27BB3D9EA6CD9A725AC2B059FFFE9E18902FBBE25D201379347FB775B08E97E861\r\ndata = bytes.fromhex(hex_input)\r\nkey = int.from_bytes(data[-4:], \"big\")\r\noutput = encryption_algo(key, data)\r\nAuto-color will store the encrypted configuration in a file for later use. If running as root, it uses\r\n/var/log/cross/config-err-X . If not, it will use /tmp/cross/config-err-X . This X is a hexadecimal value\r\ngenerated dynamically using the following formula; the used seed is extracted from the decrypted configuration:\r\na4 = 0xCE7C0B42;\r\nfor (i = 0; i \u003c v20; ++i)\r\n a4 = (0x3FFFF * a4) + *(seed + i);\r\nConnecting to C2 ServerPermalink\r\nAuto-color establishes a communication channel with its Command and Control (C2) server using a TCP socket.\r\nThis allows the malware to receive commands from the attacker and send back responses.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 8 of 19\n\nIt first parses the decrypted config to extract the required network components protocol, hostname (C2 domain or\r\nIP), and port. Once extracted, it resolves the hostname into an IP address, ensuring it can communicate directly\r\nwith the server (some configs come with direct IPs ). The resolved IP is then stored in a shared memory segment\r\nused to track previously used IPs for C2 communication.\r\nFinally, Auto-color establishes a non-blocking TCP socket. And performs an authentication step. It generates a\r\npseudo-random number and derives three challenge values by XOR-ing it with constants. These values are sent to\r\nthe C2 server, which must respond with the correct transformed values. If the response is incorrect, the connection\r\nis terminated.\r\nFigure(9): The authentication step\r\nEach sent message consists of a header and a payload. The header includes a dynamically generated encryption\r\nkey, a session ID, a status flag, and the payload size. It first encrypts and sends the header, followed by encrypting\r\nand sending the payload. If any step fails, an error code is returned. Both of them are encrypted using a custom\r\nencryption algorithm, which is the reverse of the algorithm used for decrypting the configuration.\r\nHere’s its python version :\r\n for i in range(size):\r\n key = 1023 * key - 0x70E52827\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 9 of 19\n\nres_data[i] = ((key \u003e\u003e 3) + enc_data[i]) ^ (key \u003e\u003e 11) + (key \u003e\u003e 19)\r\n return size - 1\r\nEach received message consists of an encrypted header followed by an encrypted payload. Auto-color first\r\nreceives the encrypted header and decrypts it using a custom decryption algorithm, the same algorithm used for\r\ndecrypting the configuration.\r\nThe decrypted header includes a key, a command ID, a status flag, and the payload size. After validating the\r\nheader, Auto-color receives the encrypted payload and decrypts it using the same algorithm, but with the key\r\nextracted from the header.\r\nExecuting C2 CommandsPermalink\r\nAfter retrieving the C2 command ID and performing the necessary decryption, the malware validates the\r\ncommand and routes it for execution.\r\nCommand - 0x1Permalink\r\nThis command gathers detailed information about the infected system and then sends that data to a Command and\r\nControl (C2) server.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 10 of 19\n\nFigure(10): Collect data about the host\r\nInfo Collected Description\r\nSystem Date The current date (year, month, day).\r\nOS Version Details about the operating system (e.g., version, release).\r\nHostname The name of the system (unique identifier).\r\nUsername The name of the currently logged-in user.\r\nIP Addresses The system’s internal or external IP addresses.\r\nProcessor Info The model of the system’s CPU\r\nTotal Memory The total amount of system RAM (memory).\r\nTotal Disk Space The total available disk space on the system.\r\nProcess ID The ID of the currently running process.\r\nExecutable Path The file path of the program that is currently running.\r\nIt also sends the configuration associated with the sample, as this configuration can change between different\r\ninfections.\r\nCommand - 0xFPermalink\r\nThis command deletes system files and directories associated with the malware, including the /var/log/cross\r\ndirectory and its contents, as well as the modified /etc/ld.so.preload . After cleaning up these files, it\r\nterminates the malware itself by calling kill() with its process ID .\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 11 of 19\n\nCommand - 0x400Permalink\r\nThis command reads the configuration and sends it to the C2 server. If no config is found, it sends a default value\r\ninstead.\r\nCommand - 0x401Permalink\r\nThis command modifies the configuration and the config file using a received payload. If successful, it sets a\r\nglobal flag to 1. Finally, it sends a response back to the C2 server\r\n0 if it failed\r\nthe new config file path if successful.\r\nCommand - 0x201Permalink\r\nThis command scans a selected directory obtained from the C2 server, gathers metadata about its files and\r\nsubdirectories, and sends the collected information back.\r\nIt checks whether each path is a file or a directory and collects details such as permissions (read, write, execute),\r\ntimestamps (creation, modification, access), and file size. If it finds a directory, it looks for subdirectories and\r\nmarks them accordingly.\r\nAll gathered data is structured and transmitted in an encrypted packet.\r\nCommand - 0x202Permalink\r\nThis command is used to send or receive files between the infected machine and the C2 server.\r\nIf the task is to download a file (“R2L”), it opens the file and sends its contents in chunks. If the task is to upload a\r\nfile (“L2R”), it creates or opens a file and writes the incoming data from the C2 server.\r\nCommand - 0x204Permalink\r\nThis command creates a directory or file on the host based on the command received from the C2 server. Finally,\r\nIt sends a response back to the C2 server with the status of the operation.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 12 of 19\n\nCommand - 0x205Permalink\r\nThis renames a file or directory based on a command from the C2 server. It retrieves the old and new names tries\r\nto rename the target and sends a response back to the C2 server indicating success or failure .\r\nCommand - 0x206Permalink\r\nThis deletes a file or directory as it retrieves the file or directory name and tries to remove it. Finally, it sends a\r\nresponse back to the C2 server indicating success or failure.\r\nCommand - 0x100Permalink\r\nAuto-color creates a reverse shell, allowing a remote server to interact directly with the victim host. It sets up\r\ncommunication channels using pipes, forks a new process, and launches an interactive Bash shell /bin/bash -i .\r\nThe child process shifts input/output, clears the command record, and modifies environment variables to evade\r\ndetection.\r\nThe parent process sets an encrypted connection with the remote server, manages execution threads, and ensures\r\ncleanup by terminating the shell if needed.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 13 of 19\n\nCommand - 0x300Permalink\r\nThis command lets Auto-color use the infected machine as a proxy, relaying connections between the attacker and\r\na remote target. It does this by using two sockets: one for receiving connections from the command-and-control\r\n(C2) server and another for connecting to a target IP, which is retrieved from the C2 server.\r\nThe first socket listens for incoming connections, while the second establishes communication with the target. It\r\nthen uses select() to monitor both sockets for incoming data. When data is received from the attacker, it is\r\nforwarded to the target, and when data is received from the target, it is sent back to the attacker.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 14 of 19\n\nAnalysis of libcext.so.2Permalink\r\nThis library is designed with two primary goals: evading detection and ensuring persistence.\r\nProtecting /etc/ld.preloadPermalink\r\nAuto-color’s malicious library employs various hooks to manipulate system calls, ensuring that\r\n/etc/ld.so.preload remains protected, and persistent by turning any operation involving it to\r\n/etc/ld.so.preload.xxx . If an attempt is made to delete /etc/ld.so.preload.xxx , the operation is allowed\r\nsince only the malware creates this file.\r\nHooked API Purpose\r\nchmod , fchmodat Prevents permission changes\r\nremove , unlink , unlinkat Prevents deletion\r\nrename , renameat Prevents renaming\r\nstat , lstat , fstat , fstatat , statx , _lxstat Hides presence\r\naccess , faccessat Hides presence\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 15 of 19\n\nHooked API Purpose\r\nrealpath , getattr Prevents file path resolution\r\nopen , openat , fopen Prevents access\r\nread , pread Hides malicious content\r\nopendir , readdir , scandir Hides directory entries\r\nPersistancePermalink\r\nIt retrieves the name of the calling process and checks if it matches one of the following system daemons :\r\n/sbin/auditd\r\n/sbin/cron\r\n/sbin/crond\r\n/sbin/acpid\r\n/sbin/atd\r\n/usr/sbin/auditd\r\n/usr/sbin/cron\r\n/usr/sbin/crond\r\n/usr/sbin/acpid\r\n/usr/sbin/atd\r\nAs these daemons (background processes) run continuously in a normal system, they are a perfect choice for\r\npersistence. If a match is found, it forks a new process and then uses execl() to launch the auto-color, ensuring\r\nit runs within a trusted system service while the parent process exits to stay stealthy.\r\nFigure(11): Persistence function\r\nHiding Network ActivityPermalink\r\nAuto-color’s malicious library also hides its Command and Control (C2) network activity by blocking tries to read\r\n/proc/net/tcp . This special Linux file lists all active TCP connections, including source/destination IPs and\r\nports.\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 16 of 19\n\nBy hooking different file access functions [open, openat64, fopen, and fopen64 ], it detects when a process tries to\r\nread this file. Instead of returning the actual data, It parses each entry, compares it against specific C2-related IPs\r\nand ports stored by Auto-color previously in shared memory, and filters them out.\r\nThe cleaned-up data is saved in a temporary file at /tmp/17EF88CF , allowing the malware to reuse it while\r\nkeeping the changes hidden from tools like netstat or system monitors.\r\nYARA RulePermalink\r\nrule detect_Auto_Color\r\n{\r\n meta:\r\n description = \"Detects Auto-color malware family \"\r\n author = \"Mohamed Ezzat (@ZW01f)\"\r\n hash1 = \"815b74947d3a78a1b7d2aece43596ddc0ffc264e26092f1f9b6409c62e1437d6\"\r\n hash2 = \"270fc72074c697ba5921f7b61a6128b968ca6ccbf8906645e796cfc3072d4c43\"\r\n strings:\r\n $elf = \"\\x7fELF\" // ELF header\r\n $s1 = \"/var/log/cross\"\r\n $s2 = \"/tmp/cross\"\r\n $s3 = \"/door-%d.log\"\r\n $s4 = \"/etc/ld.so.preload.xxx\"\r\n $s5 = \"%s/auto-color\" ascii wide\r\n $s6 = \"%s memory dump %d bytes...\" wide ascii\r\n condition:\r\n (filesize \u003c 300KB) and ($elf at 0) and (5 of ($s*))\r\n}\r\nfrom elftools.elf.elffile import ELFFile\r\nimport re\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 17 of 19\n\ndef extract_data_section(filename):\r\n with open(filename, \"rb\") as f:\r\n elf = ELFFile(f)\r\n \r\n for section in elf.iter_sections():\r\n if section.name == \".data\":\r\n return section.data()\r\n \r\n return None\r\ndef custom_crypto_algo(key, data):\r\n length = len(data)\r\n decrypted = bytearray(length)\r\n \r\n for i in range(length):\r\n key = (1023 * key - 0x70E52827) \u0026 0xFFFFFFFF\r\n decrypted[i] = ((data[i] - (key \u003e\u003e 19)) ^ (key \u003e\u003e 11)) - (key \u003e\u003e 3) \u0026 0xFF\r\n \r\n return decrypted\r\ndef extract_c2_urls(text):\r\n pattern = r'TCP://[a-zA-Z0-9.-]+:\\d+' # c2 URL come in : TCP://hostname_or_ip:PORT\r\n return re.findall(pattern, text, re.IGNORECASE)\r\ndef main():\r\n file_path = input(\"Enter the file path: \")\r\n data_section = extract_data_section(file_path)\r\n enc_data_offset = 0x24 #The config data begins at offset 0x24 inside the .data section\r\n size_offset = 0x20\r\n \r\n size = int.from_bytes(data_section[size_offset:enc_data_offset], byteorder='big')\r\n enc_config = data_section[enc_data_offset:enc_data_offset + size]\r\n key = int.from_bytes(enc_config[-4:], \"big\") # key is the last 4 bytes\r\n \r\n decrypted_data = custom_crypto_algo(key, enc_config).decode(\"utf-8\", errors=\"ignore\")\r\n print(\"Decrypted config :\" ,decrypted_data)\r\n \r\n extracted_url = extract_c2_urls(decrypted_data)\r\n if extracted_url:\r\n print(\"Extracted C2 URLs :\")\r\n for address in extracted_url:\r\n print(address)\r\nif __name__ == '__main__':\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 18 of 19\n\nmain()\r\nReferencesPermalink\r\nNew Linux Malware ‘Auto-color’ Grants Hackers Full Remote Access to Compromised Systems\r\nSource: https://zw01f.github.io/malware%20analysis/auto-color/\r\nhttps://zw01f.github.io/malware%20analysis/auto-color/\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://zw01f.github.io/malware%20analysis/auto-color/"
	],
	"report_names": [
		"auto-color"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434687,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/590d6486d3f9bf48e1005ce46f8ae6433bf7bc49.pdf",
		"text": "https://archive.orkl.eu/590d6486d3f9bf48e1005ce46f8ae6433bf7bc49.txt",
		"img": "https://archive.orkl.eu/590d6486d3f9bf48e1005ce46f8ae6433bf7bc49.jpg"
	}
}