{
	"id": "4950c902-ad22-4f2a-b57e-91b9f0d56525",
	"created_at": "2026-04-06T00:21:09.64446Z",
	"updated_at": "2026-04-10T03:20:26.274113Z",
	"deleted_at": null,
	"sha1_hash": "cab44707ca6ae113e142bdb027151e2bcf982d91",
	"title": "StealC Malware Analysis Part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 746630,
	"plain_text": "StealC Malware Analysis Part 2\r\nArchived: 2026-04-06 00:03:34 UTC\r\n04 - Loader analysis (Stage 2)\r\nStage 2 information\r\nIn the previous article, we retrieved Stage2 (a PE) encrypted and embedded in Stage1.\r\nA first phase of research can be interesting in order to retrieve some pieces of information. If you're working on a new\r\nsample, it's likely to be missing from IOC and sample sharing platforms such as VirusTotal, MalwareBazaar... At this point,\r\nyou'll need to use sandboxes, as described in the Reminders and preparation of the analysis environment chapter.\r\nInformation on Stage 2 is given below:\r\nType Data\r\nSHA256 9874c7bd9d008c8a7105c8e402813204d5c3ddc3fb8d1aaddbb0e19d65062dfb\r\nSHA1 8cfd1de05578d750b296d13f6f8bc1d78d42a891\r\nMD5 999af7adf5fa30b3d748da1b2e84affd\r\nFile size 427.50 KB (437760 bytes)\r\nFirst seen 2024-04-16 14:48:13 UTC (VirusTotal)\r\nMagic PE32 executable (GUI) Intel 80386, for MS Windows\r\nimphash cdfd758783fcb7e7c9a9010b0d1ea06a\r\nssdeep 6144:XI+yLuPAYp/YKaUdAOmNGZxYSwkrVEi597BoVAw5:zyL2AYp/Hl8NMYSwkrVEiZoVR5\r\nDetonation in a sandbox\r\nWe will detonate the sample in a sandbox disconnected from the network to avoid leaving traces on the Internet and alerting\r\nthe malicious actor. If you're on an incident response mission, or need to work on a sample requiring a high level of\r\ndiscretion, it's best not to submit the sample online.\r\nTo do this, you can install an open-source sandbox such as Cape Sandbox. You can follow the documentation to set up the\r\nsandbox on a server supporting virtualization. If you can't afford to host a Cape-type solution, you can detonate the sample\r\nin your Windows virtual machine. We recommend setting up a system such as Inetsim to simulate a network environment\r\nand detect potential requests made by the sample.\r\nOnce the sandbox is set up on your side, you can detonate the sample (Stage 2) to gather more information about it.\r\nWhen we run the sample in the sandbox, we can see that the dummy sample of Inetsim is executed. This lets us know that\r\nan executable has been downloaded from the network and run:\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 1 of 10\n\nGuest VM sandbox with Inetsim\r\nIf you look at the logs of your Inetsim service, you should find more or less the same elements that Cape Sandbox can\r\nshow you:\r\nCape Sandbox signature - Loader (Stage 2)\r\nThanks to this detonation, we are able to understand that the sample is a loader and executes stage 3. We can draw up the\r\nfollowing IOC list:\r\nType IOC\r\nipv4 185.172.128[.]90\r\nipv4 185.172.128[.]228\r\nipv4 185.172.128[.]59\r\nipv4 185.172.128[.]228\r\nfilename BroomSetup.exe\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 2 of 10\n\nType IOC\r\nfilename syncUpd.exe\r\nurl hxxp://185[.]172.128.90/cpa/ping.php?substr=0\u0026s=ab\u0026sub=0\r\nurl hxxp://185[.]172.128.228/ping.php?substr=0\r\nurl hxxp://185[.]172.128.59/syncUpd.exe\r\nurl hxxp://185[.]172.128.228/BroomSetup.exe\r\nSample recovery\r\nTo prevent the malicious infrastructure from shutting down its services, if your level of discretion allows it, you can\r\ndownload the supposedly malicious samples ( syncUpd.exe and BroomSetup.exe ). To do this, we recommend not using\r\nyour exit IP directly, so as not to communicate with the malicious infrastructure. You can, for example, use the Tor network\r\nor a VPN provider, or even your own server hosted remotely and dedicated to this type of use.\r\nSome malicious actors may block specific IP addresses, such as Tor exit nodes, User-Agent and so on. If you are faced with\r\nthis type of problem, don't hesitate to reproduce a victim's execution environment as closely as possible. The location of an\r\nIP address can have an effect on C2's decision to respond to you. If the actor is targeting France, it's best to use a French IP.\r\nFrom your sandbox, you can retrieve the User-Agent used by Stage 2 to carry out its request.\r\nCape Sandbox - HTTP requests from Stage 2 (Loader)\r\nIn our case, the malicious actor doesn't seem to be filtering. We can use curl via Tor to download the sample (the URLs\r\nhave been deliberately filtered by us to avoid misuse by a reader):\r\ntorify curl -A \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.129 Sa\r\ntorify curl -A \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.129 Saf\r\nWhen you search for the cryptographic fingerprint of the two samples on VirusTotal, you'll find that BroomSetup.exe is a\r\nlegitimate program, while syncUpd.exe is identified as malicious. If you run a Yara scan with the rule we wrote in the\r\nStage 1 chapter, you'll find that syncUpd.exe is packed with the same packer as Stage 1! We'll look at how to unpack it in\r\nthe next chapter.\r\nIt's highly likely that by the time you take this article, the executables will no longer be accessible from the malicious actor's\r\nC2. We can send them to you on request.\r\nIf the sandbox method is all you need to retrieve C2 from the malicious actor, you can proceed to the next chapter. In the\r\nnext section, we'll use MIASM to retrieve HTTP requests directly.\r\nRetrieving loader requests with MIASM\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 3 of 10\n\nOur Stage 2 (loader) appears to make HTTP requests to an IP address to transmit information, retrieve and then execute\r\npossibly malicious samples.\r\nA sandbox can in some cases work if no antiVM system is in place in the sample. A sandbox may take some time to run and\r\nproduce a report. If you need to scale up IOC extraction, you can automate the extraction process. As seen in the previous\r\narticle on Stage 1, we'll look at how to retrieve these URLs with the MIASM framework.\r\nPrepare your virtual environment, install MIASM, and let's start with a new example script provided by MIASM. As you\r\ndevelop the script, you may find it useful to open the sample in a disassembler to understand why it is not executing as\r\ndesired.\r\nTo start with, you can add the default options to introduce the environment required to run our sample:\r\noptions.usesegm = True\r\noptions.use_windows_structs = True\r\noptions.load_hdr = True\r\noptions.dependencies = True\r\nRun the script and add the missing WinAPI methods as described in the previous article. For example:\r\n[INFO ]: kernel32_GetProcAddress(libbase=0x7111e000, fname=0x4293b4) ret addr: 0x40dae2\r\nTraceback (most recent call last):\r\n File \"/home/user/Dev/test_stealc/stage2_loader_miasm.py\", line 21, in \u003cmodule\u003e\r\n sb.run()\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/analy\r\n super(Sandbox_Win_x86_32, self).run(addr)\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/analy\r\n self.jitter.continue_run()\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/jitte\r\n return next(self.run_iterator)\r\n ^^^^^^^^^^^^^^^^^^^^^^^\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/jitte\r\n for res in self.breakpoints_handler.call_callbacks(self.pc, self):\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/jitte\r\n res = c(*args)\r\n ^^^^^^^^\r\n File \"/home/user/Dev/test_stealc/venv/lib/python3.11/site-packages/miasm-0.1.5.dev47-py3.11-linux-x86_64.egg/miasm/jitte\r\n raise ValueError('unknown api', hex(jitter.pc), repr(fname))\r\nValueError: ('unknown api', '0x7111e004', \"'api-ms-win-core-synch-l1-2-0_InitializeCriticalSectionEx'\")\r\nThis function can be implemented as follows:\r\ndef InitializeCriticalSectionEx(jitter):\r\n #api-ms-win-core-synch-l1-2-0_InitializeCriticalSectionEx\r\n ret_ad, _ = jitter.func_args_stdcall([\"lpCriticalSection\",\r\n \"dwSpinCount\", \"Flags\"])\r\n jitter.func_ret_stdcall(ret_ad, 1)\r\n[...]\r\ng = globals()\r\ng['api-ms-win-core-synch-l1-2-0_InitializeCriticalSectionEx'] = InitializeCriticalSectionEx\r\n[...]\r\nsb = Sandbox_Win_x86_32(loc_db, options.filename, options, g)\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 4 of 10\n\nThe principle remains the same for the following methods, which will trigger crashes. You'll get to the interesting part once\r\nyou've triggered the error for the ws2_32_gethostbyname method. Here's an example of an implementation that displays the\r\ndomain or IP address sent as a parameter to the method, and returns 127.0.0.1 in the hostent structure so that the\r\nprogram can continue running:\r\nimport struct\r\nimport logging\r\nfrom miasm.core.utils import pck32\r\nfrom miasm.os_dep.common import set_win_str_w, get_win_str_w, get_win_str_a\r\n[...]\r\nlog = logging.getLogger(\"loader_c2_retriever\")\r\nconsole_handler = logging.StreamHandler()\r\nconsole_handler.setFormatter(logging.Formatter(\"[%(levelname)-8s]: %(message)s\"))\r\nlog.addHandler(console_handler)\r\nlog.setLevel(logging.INFO)\r\n[...]\r\ndef ws2_32_gethostbyname(jitter):\r\n \"\"\"\r\n struct hostent* gethostbyname(\r\n const char* name\r\n )\r\n \"\"\"\r\n ret_ad, args = jitter.func_args_stdcall([\"name\"])\r\n domain = get_win_str_a(jitter, args.name)\r\n log.info(f\"[\u003e] C2: {domain}\")\r\n ip_str = \"127.0.0.1\"\r\n ip = bytes((int(octet) for octet in reversed(ip_str.split('.'))))\r\n list_item = winobjs.heap.alloc(jitter, len(ip))\r\n jitter.vm.set_mem(list_item, ip)\r\n addr_list = winobjs.heap.alloc(jitter, 2 * 8)\r\n jitter.vm.set_mem(addr_list + 0 * 8, pck32(list_item))\r\n jitter.vm.set_mem(addr_list + 1 * 8, pck32(0))\r\n d_nullptr = addr_list + 1 * 8\r\n hostent_obj = struct.pack(\r\n \"IIHHI\",\r\n args.name, # h_name\r\n d_nullptr, # h_aliases\r\n 2, # h_addrtype\r\n len(ip), # h_length\r\n addr_list # h_addr_list\r\n )\r\n hostent_addr = winobjs.heap.alloc(jitter, len(hostent_obj))\r\n jitter.vm.set_mem(hostent_addr, hostent_obj)\r\n jitter.func_ret_stdcall(ret_ad, hostent_addr)\r\n[...]\r\nYou should get the following output:\r\n[INFO ]: [\u003e] C2: 185[.]172.128.90\r\nContinue with the implementation of the ws2_32_ntohs and ws2_32_connect methods. When you reach the\r\nws2_32_send method, you'll be able to retrieve the first HTTP request made by the loader. You can retrieve its contents as\r\nfollows:\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 5 of 10\n\nfrom http.server import BaseHTTPRequestHandler\r\nfrom io import BytesIO\r\n[...]\r\nclass HTTPRequest(BaseHTTPRequestHandler):\r\n def __init__(self, request_text):\r\n self.rfile = BytesIO(request_text)\r\n self.raw_requestline = self.rfile.readline()\r\n self.error_code = self.error_message = None\r\n self.parse_request()\r\n def send_error(self, code, message):\r\n self.error_code = code\r\n self.error_message = message\r\ndef ws2_32_send(jitter):\r\n \"\"\"\r\n [SocketCode-int] send(\r\n SOCKET s,\r\n LPVOID buf,\r\n int len,\r\n [SendRecvFlags] flags\r\n )\r\n \"\"\"\r\n ret_ad, args = jitter.func_args_stdcall([\"s\", \"buf\", \"len\", \"flags\"])\r\n data_to_send = jitter.vm.get_mem(args.buf, args.len)\r\n log.debug(f\"[\u003e] Data sent to the server:\\n{data_to_send}\")\r\n try:\r\n request = HTTPRequest(data_to_send)\r\n host = request.headers['host']\r\n path = request.path\r\n protocol = \"\"\r\n if LAST_SOCKET_PORT == 80:\r\n protocol = \"http://\"\r\n log.info(f\"[\u003e] Requested URL : {protocol}{host}:{LAST_SOCKET_PORT}{path}\")\r\n except:\r\n pass\r\n jitter.func_ret_stdcall(ret_ad, args.len)\r\nThis gives you the following output:\r\n[INFO ]: [\u003e] Requested URL : hxxp://185[.]172.128.90:80/cpa/ping.php?substr=0\u0026s=ab\u0026sub=0\r\nYou then need to implement the ws2_32_recv method so that the loader can validate that the request has been passed to\r\ncontinue execution.\r\nYou can stop development when you reach the kernel32_DeleteCriticalSection method. You can then disable MIASM's\r\nverbosity to display only relevant information:\r\n#Disable miasm log\r\nlogging.getLogger(\"jit function call\").disabled = True\r\nlogging.getLogger(\"loader_common\").disabled = True\r\nlogging.getLogger(\"loader_pe\").disabled = True\r\nlogging.getLogger(\"seh_helper\").disabled = True\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 6 of 10\n\nThis gives you the following result:\r\n[INFO ]: [\u003e] C2: 185.172.128[.]90\r\n[INFO ]: [\u003e] C2 port : 80\r\n[INFO ]: [\u003e] Requested URL : hxxp://185[.]172.128.90:80/cpa/ping.php?substr=0\u0026s=ab\u0026sub=0\r\n[INFO ]: [\u003e] C2: 185.172.128[.]228\r\n[INFO ]: [\u003e] C2 port : 80\r\n[INFO ]: [\u003e] Requested URL : hxxp://185.172[.]128.228:80/ping.php?substr=0\r\n[INFO ]: [\u003e] C2: 185.172[.]128.59\r\n[INFO ]: [\u003e] C2 port : 80\r\n[INFO ]: [\u003e] Requested URL : hxxp://185[.]172.128.59:80/syncUpd.exe\r\nYou will find the complete code that produced the above result here.\r\nIn the next chapter, we'll find out what's behind the syncUpd.exe program (stage 3).\r\n05 - Analysis of Stage 3\r\nStage 3 information\r\nOnce we've retrieved the sample from the malicious actor's C2, we can begin analyzing it without further ado.\r\nHere's the information about the sample we will analyze in this chapter:\r\nType Data\r\nSHA256 b1a73a20fb4a434c77aeabd506a0995b8c7c22bbbb4824584cdecb63ca198291\r\nSHA1 381bf37ae4c081752a3e62b1d5ee612ea4c0595c\r\nMD5 28b12dbd2041c716ad7d8525d58b7f42\r\nFile size 271 872 bytes\r\nFirst\r\nseen\r\n2024-04-30 13:00:51 UTC (VT)\r\nMIME\r\ntype\r\napplication/x-dosexec\r\nimphash 6238cdaa05523d29a8e8e1952e0934c6\r\nssdeep 3072:Km3ix/rp+xVl7hDB+R+z/+gT0J+QWNKiwfAZtvcX8VP3YsxG8fjxWo3tIIbbJZ:SjUPNhV+RngT1DLvWy33giW\r\nThe executable is present on VirusTotal and has a high detection ratio. We can run a Yara scan on the file and identify known\r\nmarkers. It turns out that the executable matches a rule we wrote in this article ( pkr_ce1a ):\r\n$ yara -s Packer_pkr_ce1a.yar ./syncUpd.exe\r\nPacker_pkr_ce1a_generic ./Dev/test_stealc/syncUpd.exe\r\n0x187ef:$shellcode_size: 00 69 9A F9 74 C5 32 00 00 96 AA CB 46 00\r\n0x187c3:$shellcode_addr: 00 94 48 8D 6A 6D 98 40 00 F2 16 0B 68 00\r\n0x88b:$tea_const_delta: B9 79 37 9E\r\n0x837:$tea_sum_calculated1: 81 01 E1 34 EF C6\r\nWe're back to identifying the shellcode and cryptographic constants of the TEA algorithm!\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 7 of 10\n\nUnpacking stage 3\r\nAs we took the time to implement an unpacker with MIASM in Chapter 1, we're going to reuse it to unpack the sample. We\r\ncan see that the program fits into new anti-emulation methods:\r\n....\r\n[INFO ]: kernel32_EncodePointer(0x20009010) ret addr: 0x403688\r\n[INFO ]: kernel32_LeaveCriticalSection(lpCriticalSection=0x430568) ret addr: 0x406f96\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n[INFO ]: kernel32_SetLastError(errcode=0x0) ret addr: 0x401cbb\r\n[INFO ]: kernel32_GetTickCount() ret addr: 0x401cb4\r\n....\r\nIf we compare the impacted code portions using a tool such as BinDiff , we find our anti-emulation loop, except that the\r\narguments sent as parameters are not the same. As a result, the WinAPI methods are different too:\r\nBinDiff - Anti-Emulation loops (Case 1)\r\nIn Stage 1, the GetCurrentProcessId and GetCurrentProcess methods were used. In Stage 3, these methods have been\r\nreplaced by GetTickCount and SetLastError .\r\nAnother example:\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 8 of 10\n\nBinDiff - Anti-Emulation loops (Case 2)\r\nIt seems that the malicious actor is changing the WinAPI methods used for anti-emulation. We could improve our anti-emulation bypass to be more generic, for example by identifying the loop using common instructions or constants. The latest\r\nbasic blocks seem to contain fixed constants with the values 0x7a45f535 and 0xe154 . The packer may evolve and change\r\nthese values. It may be preferable to use several identification criteria.\r\nFor the purposes of this article, we're not going to opt for a perfect method. Here we're just going to get around anti-emulation by changing the return addresses or changing the values of specific registers:\r\n#\r\n# Stage 3 (b1a73a20fb4a434c77aeabd506a0995b8c7c22bbbb4824584cdecb63ca198291)\r\n#\r\ndef kernel32_GetTickCount(jitter):\r\n ret_ad, _ = jitter.func_args_stdcall(0)\r\n winobjs.tickcount += 1\r\n # AntiEmulation @0x00401cae (b1a73a20fb4a434c77aeabd506a0995b8c7c22bbbb4824584cdecb63ca198291)\r\n if ret_ad == 0x00401cb4:\r\n ret_ad = 0x00401d16\r\n jitter.func_ret_stdcall(ret_ad, winobjs.tickcount)\r\ndef kernel32_GetLastError(jitter):\r\n ret_ad, _ = jitter.func_args_stdcall(0)\r\n # AntiEmulation @0x00401708 (b1a73a20fb4a434c77aeabd506a0995b8c7c22bbbb4824584cdecb63ca198291)\r\n if ret_ad == 0x40170e: # anti emu\r\n jitter.cpu.EDI = 0x1\r\n jitter.func_ret_stdcall(ret_ad, winobjs.lastwin32error)\r\ndef kernel32_SetLastError(jitter):\r\n ret_ad, args = jitter.func_args_stdcall([\"errcode\"])\r\n # AntiEmulation @0x004017ca (b1a73a20fb4a434c77aeabd506a0995b8c7c22bbbb4824584cdecb63ca198291)\r\n if ret_ad == 0x4017d0: # anti emu\r\n if jitter.cpu.EDI \u003e 0x62:\r\n ret_ad = 0x004017e3\r\n else:\r\n jitter.cpu.EDI = 0x62\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 9 of 10\n\nprint(hex(jitter.cpu.EDI))\r\n winobjs.lastwin32error = args.errcode\r\n jitter.func_ret_stdcall(ret_ad, 0)\r\nOnce the new code has been executed, you should be able to extract a new sample:\r\n[INFO ]: kernel32_VirtualProtect(lpvoid=0x400000, dwsize=0x23b000, flnewprotect=0x40, lpfloldprotect=0x13e004) ret add\r\n[WARNING ]: set page 400000 7\r\n[WARNING ]: set page 401000 7\r\n[WARNING ]: set page 411000 7\r\n[WARNING ]: create page 419000 7\r\n[WARNING ]: create page 63b000 7\r\n[INFO ]: kernel32_VirtualFree(lpvoid=0x2004b000, dwsize=0x0, alloc_type=0x8000) ret addr: 0x20024446\r\nPE unpacked : 'syncUpd_exe_miasm_unpacked.bin' (Region : 0x2004b000)\r\nLet's check the magic of this file:\r\n$ file syncUpd_exe_miasm_unpacked.bin\r\nsyncUpd_exe_miasm_unpacked.bin: PE32 executable (GUI) Intel 80386, for MS Windows, 4 sections\r\nThe complete code for unpacking syncUpd.exe is available here.\r\nWe can now go on to the next article to see what's behind the program we've just extracted.\r\nSource: https://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nhttps://blog.lexfo.fr/StealC_malware_analysis_part2.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.lexfo.fr/StealC_malware_analysis_part2.html"
	],
	"report_names": [
		"StealC_malware_analysis_part2.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434869,
	"ts_updated_at": 1775791226,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cab44707ca6ae113e142bdb027151e2bcf982d91.pdf",
		"text": "https://archive.orkl.eu/cab44707ca6ae113e142bdb027151e2bcf982d91.txt",
		"img": "https://archive.orkl.eu/cab44707ca6ae113e142bdb027151e2bcf982d91.jpg"
	}
}