{
	"id": "2cba406e-4cdd-4b1a-920d-380c07feb1c3",
	"created_at": "2026-04-06T00:21:19.03557Z",
	"updated_at": "2026-04-10T03:21:15.980863Z",
	"deleted_at": null,
	"sha1_hash": "f445fa90756c48a153ddc2bbe57a9b633ce6a344",
	"title": "Analyzing Vidar Stealer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 7058149,
	"plain_text": "Analyzing Vidar Stealer\r\nArchived: 2026-04-05 15:47:43 UTC\r\n1.\r\n2. Blog\r\n3. Analyzing Vidar Stealer\r\nPrevious Post Phorpiex Malware Analysis\r\nNext Post Breaking Down A Multi-Stage PowerShell Infection\r\nOverview\r\nVidar is an infostealing malware designed to collect a variety of sensitive information from an infected computer\r\nand exfiltrate it to an attacker. It operates as malware-as-a-service (MaaS) and has been widely used by\r\ncybercriminals since its discovery in late 2018.\r\nVidar is typically distributed to victims via phishing emails and fake installers. I have personally seen many fake\r\ninstallers containing some type of stealer, such as cracked software, game cheats, keygens, and more.\r\nHere’s an infection flow that I’ve created for what we’re going to analyze today. This is just to give you a general\r\nidea of the infection chain and is not 100% accurate:\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 1 of 28\n\nSample Information\r\nMD5: b6fff0854975fdd3a69fd2442672de42\r\nSHA256: fe0d2c8f9e42e9672c51e3f1d478f9398fe88c6f31f83cadbb07d3bb064753c6\r\nSize: 270,336 bytes\r\nCompilation date: 2025-03-13 10:34:19\r\nLoader Analysis\r\nStatic Analysis\r\nThe first thing I do in every investigation involving files is gain an overview of the files and their capabilities,\r\nencryption used, obfuscation, and packers. At this stage, I make hypotheses about the file’s capabilities and goals\r\nso I can focus on the important aspects and avoid unnecessary rabbit holes.\r\nDropping the file into Detect it easy, it didn’t identify any known packers, and it seemed like the sample was\r\ncompiled with Microsoft Visual C/C++(2022+)[-] using the Microsoft Linker(14.42).\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 2 of 28\n\nAs seen above, the sample appears to be 64-bit. We can verify this by checking the magic header in the optional\r\nheader of the PE file. A value of 0x20B indicates a 64-bit file, while 0x10B signifies a 32-bit file.\r\nAs we can see, this is indeed 0x20B (Little Endian) which means this is 64-bit file.\r\nNext, let’s check the compilation time. We can examine the TimeDateStamp , which contains a DWORD (4 bytes)\r\nvalue representing the time of compilation.\r\nIn order to get the actual value, we need to convert it to big endian and then to decimal. The value is stored as\r\nepoch time (also known as Unix time), which is how computers store and measure time, so we need to convert it\r\naccordingly.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 3 of 28\n\nAs we can see, after all the conversions, the compilation date is 2025-03-13 . We can verify this by checking any\r\nPE parser, i.e., CFF Explorer, PE Bear, and others.\r\nChecking the entropy of the file reveals that the .BSS section has high entropy. This section usually contains\r\nuninitialized global and static objects, so high entropy could indicate that it contains encrypted shellcode or\r\nadditional payloads for the malware. It’s actually common for attackers to store encrypted shellcode in the .BSS\r\nand .data sections, but we’ll revisit this later.\r\nChecking the imports reveals functionality that could be used for anti-analysis and anti-debugging, such as\r\nUnhandledExceptionFilter , SetUnhandledExceptionFilter , IsDebuggerPresent , and\r\nGetEnvironmentStringsW . Additionally, there are functions that suggest potential malicious functionality.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 4 of 28\n\nRunning Strings/Floss against the file didn’t yield any interesting results.\r\nNow that we have an overview of the file, its capabilities, and potential functionality, we can start analyzing it.\r\nFirst thing that the program does is get it’s full path in order to load itself into memory, it’s using\r\nGetModuleHandleW and GetModuleFileNameA .\r\nAfter that, we can see that it opens the file in binary mode. It uses fopen , then moves the file pointer to the end\r\nwith fseek , retrieves the file size with ftell , and finally closes the file.\r\nNext, we can see that it allocates memory using the size returned from ftell, then reads the file’s contents into the\r\nbuffer.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 5 of 28\n\nNext, we can see that it loads the file’s content into the R10 register. It then retrieves the e_lfanew offset,\r\nwhich contains the address of the PE header. After that, it extracts the number of sections and checks if it is zero,\r\njumping accordingly.\r\nIf the number of sections is non-zero, it loads the effective address of a variable named .BSS . As we recall, the\r\n.BSS section had very high entropy, which further supports the idea that it contains some form of encrypted\r\nshellcode that will eventually be injected into memory.\r\nWalking the PEB (Process Environment Block)\r\n“Walking the PEB” is an approach malware authors use to interact with the Process Environment Block in\r\nWindows. This data structure holds information about the process, loaded modules, environment variables, and\r\nmore. By walking the PEB, malware authors can dynamically resolve APIs that are typically monitored by\r\nsecurity products and may be detected during static analysis.\r\nWe can see that the malware accesses the PEB at gs:60h , which is how the PEB is accessed in a 64-bit\r\narchitecture. In a 32-bit architecture, it would be accessed through fs:30h .\r\nNext, the malware moves the address of PEB_LDR_DATA into RCX . PEB_LDR_DATA is a structure that holds three\r\npointers to three doubly linked lists of loaded modules. It then accesses offset 0x20 , which corresponds to\r\nInMemoryOrderModuleList - a structure that contains all the loaded modules in memory, including DLLs.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 6 of 28\n\nWe can see the string \"KERNEL32.DLL\" . The malware will parse the InMemoryOrderModuleList , searching for\r\nthis module. If found, it returns its address.\r\nAPI Hashing\r\nAPI hashing is a common trick malware uses to hide its function calls and make static analysis harder. Instead of\r\nstoring API names like LoadLibrary or GetProcAddress in plain text, it converts them into hash values. This\r\nway, security tools and analysts can’t easily spot which APIs the malware is using just by scanning the binary.\r\nAt runtime, the malware calculates hashes for loaded APIs and compares them against its stored values to resolve\r\nwhat it needs. This is often combined with walking the PEB to find loaded modules without relying on standard\r\nWindows API calls, making detection even more difficult.\r\nAs we can see, it’s quite obvious that the malware implements API hashing. Hardcoded hash values are being\r\npassed to the sub_1400011C0 function ( ResolveFunctionByHash ), and the returned address is saved on the stack.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 7 of 28\n\nWe can create an IDAPython script to retrieve the APIs by recreating the hashing algorithm used by the malware\r\nand computing it against a list of exports from the relevant DLL - in this case, kernel32.dll . Alternatively, we\r\ncould debug it and resolve them dynamically.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 8 of 28\n\nThe combination of resolved APIs looks like a classic preparation for process injection. This also makes sense\r\nbased on what we observed in the .BSS section.\r\nDecryption of Encrypted Shellcode\r\nAfter that, I see a call to the function sub_7FF7C53B13F0 , which is responsible for the decryption routine of the\r\nencrypted shellcode. The function likely uses RC4 encryption, as indicated by the initialization of an array of 256\r\nbytes, which is part of the Key Scheduling Algorithm (KSA) in RC4.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 9 of 28\n\nOnce the array is initialized, it gets shuffled with a key.\r\nThe final step is the Pseudo-Random Generation Algorithm (PRGA) , which uses the array to generate a keystream\r\n(a pseudo-random byte sequence) that is XORed with the plaintext to produce the ciphertext.\r\nInstead of analyzing it statically, we can just dynamically analyze it, let the magic happen, and get the next stage (;\r\nUnpacking\r\nOkay, at this point, I have enough information to confidently say that we’re dealing with a loader that uses remote\r\nprocess injection to execute its next stage.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 10 of 28\n\nThere’s one neat trick that will help us unpack it with a single breakpoint. As we can see, the malware uses\r\nWriteProcessMemory . This API takes several parameters, but the third one, lpBuffer , is a pointer to the buffer\r\nthat contains data to be written into the address space of the specified process.\r\nAfter setting the breakpoint, we can inspect the third argument on the stack, where we should see the data that is\r\nabout to be written to the process. By doing this, we get the most beautiful thing -the MZ header. It seems like the\r\nmalware is trying to inject a PE file into a remote process.\r\nWe can follow the memory map and dump the process, but before that, let’s see which process it’s getting injected\r\ninto.\r\nBy following the CreateProcessA call, which we know the malware uses, we can see that the process being\r\ninjected with the PE is C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe .\r\nNow, let’s dump the next stage by following the memory map\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 11 of 28\n\nand dumping it to disk\r\nThat’s about it with the loader. Now, let’s analyze the real deal – the stealer!\r\nStealer Analysis\r\nOverview\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 12 of 28\n\nIt seems like this time we’re dealing with a 32-bit binary compiled on 2025-02-23 .\r\nRunning Strings yields quite interesting results:\r\nMultiple occurrences of strings related to crypto wallets.\r\nMultiple references to browser paths.\r\nURLs of a Telegram channel and a Steam profile.\r\nReferences to numerous files that could potentially store information about the target and passwords.\r\nData Theft\r\nBefore the stealer begins data harvesting, it downloads several DLLs from the C2 server, including:\r\nfreebl3.dll\r\nmozglue.dll\r\nmsvcp140.dll\r\nnss3.dll\r\nsoftokn3.dll\r\nvcruntime140.dll\r\nThese DLLs are legitimate and likely used by the stealer to enable parsing of relevant information and to facilitate\r\nthe necessary capabilities for data harvesting.\r\nVidar is capable of stealing a wide array of data, including:\r\nBrowser Data (history, autofill, cookies)\r\nGeneral Information (username, computer details, local time, language, installed software, processes, and\r\nmore)\r\nCrypto Wallets\r\nScreenshots of your PC\r\nAnd more\r\nLet’s go over some of the things the stealer harvests.\r\nFileZilla\r\nThe stealer seems to parse the file \\AppData\\Roaming\\FileZilla\\recentservers.xml and retrieve the hostname,\r\nport, and password if they exist.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 13 of 28\n\nWinSCP\r\nNext, the stealer opens Software\\\\Martin Prikryl\\\\WinSCP 2\\\\Configuration , which is the registry key that\r\ncontains information about the configuration in WinSCP . Then, it enumerates the values to check if Security\r\nand UseMasterPassword exist.\r\nAfter that, the stealer opens Software\\\\Martin Prikryl\\\\WinSCP 2\\\\Sessions , which is the registry key that\r\ncontains information about saved WinSCP sessions. It then enumerates the session keys and processes each one to\r\nextract details such as the HostName , PortNumber , UserName , and Password . For each session, the stealer\r\nretrieves the values of these registry keys and constructs a string with the session information. If the password\r\nexists, it is retrieved and stored as part of the session details. The information is then allocated and copied into\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 14 of 28\n\nmemory\r\nScreenshot\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 15 of 28\n\nThe stealer captures a screenshot by using GetDesktopWindow to get the window handle of the desktop, then it\r\ncalls GetDC to obtain a device context for the desktop window and creates a compatible bitmap with\r\nCreateCompatibleBitmap to store the screenshot.\r\nThen it delete any temporary objects, doing sort of a clean-up\r\nBrowser Data\r\nVidar stealer supports extracting information from the following browsers:\r\nGoogle Chrome\r\nAmigo\r\nTorch\r\nVivaldi\r\nComodo Dragon\r\nEpic Privacy Browser\r\nCocCoc\r\nBrave\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 16 of 28\n\nCent Browser\r\n7Star\r\nChedot Browser\r\nMicrosoft Edge\r\n360 Browser\r\nQQBrowser\r\nCryptoTab\r\nOpera Stable\r\nOpera GX Stable\r\nMozilla Firefox\r\nPale Moon\r\nIt seems like the stealer uses remote browser debugging to steal cookies. Besides that, it goes through all the\r\nbrowser-related files and tries to extract information from them.\r\nCrypto Wallets\r\nVidar supports stealing from various cryptocurrency wallets such as Bitcoin, Ethereum, Binance, Brave Wallet,\r\nOpera Wallet, Monero, and the list goes on. For example, the stealer opens the registry key SOFTWARE\\monero-project\\monero-core and queries the value wallet_path to check if the file wallet.keys exists.\r\nThe stealer creates an SQLite database to store information about the collected data, such as passwords, browser\r\nhistory, and other sensitive details. Here’s an example of the basic structure used to store data:\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 17 of 28\n\nThere’s so much more that Vidar stealer is capable of in terms of stealing and harvesting data, but I can’t go over\r\nall of them one by one because it would take forever.\r\nInformation Log\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 18 of 28\n\nThe stealer gathers almost all general information about the victim. After collecting the relevant data, it saves it in\r\na file named information.txt in memory and sends it to the C2 server.\r\nSome of the fields it collects are:\r\nMachine ID\r\nHWID\r\nGUID\r\nComputer Name\r\nTime Zone\r\nWindows\r\nAnd more\r\nIn order to extract the relevant information, it uses various APIs and parses registry keys to build the\r\ninformation.txt file. For example, to obtain all running processes on the system, the stealer uses the\r\nCreateToolhelp32Snapshot function to take a snapshot of all running processes. It then iterates over these\r\nprocesses using the Process32First and Process32Next functions.\r\nBesides the process enumeration function, the stealer collects information about installed programs from the\r\nregistry key HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall . It then parses the\r\nDisplayName and DisplayVersion values to list all installed software and their respective versions.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 19 of 28\n\nThis is how Information.txt looks like:\r\nVersion: 13.2\r\nDate: 20/3/2025 15:44:39\r\nMachineID: 169e761d-7c54-4ade-a217\r\nGUID: {75ac9683-f7c2}\r\nHWID: 8EBD693388E01671227304-75ac9683-f7c2\r\nPath: C:\\Users\\AviaLab\\Desktop\\v7942.exe_000002166AC90000.bin\r\nWork Dir: In memory\r\nWindows: Windows 10 Pro\r\nInstall Date: Disabled\r\nAV: Disabled\r\nComputer Name: DESKTOP-C654J0B\r\nUser Name: AviaLab\r\nDisplay Resolution: 1558x920\r\nKeyboard Languages: English (United States) / Hebrew (Israel)\r\nLocal Time: 20/3/2025 15:44:39\r\nTimeZone: -8\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 20 of 28\n\n[Hardware]\r\nProcessor: AMD Ryzen 9 7950X3D 16-Core Processor\r\nCores: 2\r\nThreads: 2\r\nRAM: 8191 MB\r\nVideoCard: VMware SVGA 3D\r\n[Processes]\r\nSystem\r\nRegistry\r\nsmss.exe\r\ncsrss.exe\r\nwininit.exe\r\ncsrss.exe\r\nwinlogon.exe\r\nservices.exe\r\nlsass.exe\r\nfontdrvhost.exe\r\n\u003c ... \u003e\r\n[Software]\r\nDigital Detective DCode v5.5 - 5.5.21194.40\r\nVisual Studio Build Tools 2017 - 15.9.61\r\nEvent Log Explorer Standard Edition 5.5 - 5.5\r\nVisual Studio Community 2022 - 17.9.6\r\nKernel OST Viewer ver 21.1\r\nKernel Outlook PST Viewer ver 20.3\r\nMalcode Analyst Pack v0.24\r\nMicrosoft Edge - 134.0.3124.72\r\nMicrosoft Edge WebView2 Runtime - 134.0.3124.72\r\nNmap 7.93 - 7.93\r\nNpcap - 1.73\r\nPDFStreamDumper 0.9.5xx\r\nvbdec\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 21 of 28\n\nWinSCP 6.1.1 - 6.1.1\r\n\u003c ... \u003e\r\nIn addition, there’s another file called passwords.txt , which appears to contain all the collected passwords. This\r\nfile is sent to the C2 during the data exfiltration process.\r\nAdditional Payloads\r\nThe stealer also acts as a downloader. Once it finishes all its harvesting activities, it downloads additional\r\npayloads to C:\\ProgramData\\\u003cGeneratedFolder\u003e\\ using InternetOpenA .\r\nWe can verify this by using a debugger. Let’s set a breakpoint on InternetOpenUrl and check the second\r\nargument passed on the stack. It should be lpszUrl , a pointer to a null-terminated string variable that specifies\r\nthe URL to begin reading.\r\nAfter that, it uses WriteFileA to write the file to C:\\ProgramData\\\u003cGeneratedFolder\u003e\\ with a newly generated\r\nname and executes it using ShellExecuteExW .\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 22 of 28\n\nSelf-Deletion\r\nOnce the malware completes all its activities, it performs self-deletion using ShellExecuteA . It does this by\r\nopening cmd.exe and running the following command:\r\n\"C:\\Windows\\system32\\cmd.exe\" /c del /f /q \"\u003cMalwarePath\u003e\" \u0026 timeout /t 11 \u0026 rd /s /q\r\n\"C:\\ProgramData\\\u003cGeneratedFolder\u003e\" \u0026 exit\r\nFirst, the malware forcefully and silently deletes its own executable with del /f /q \"\u003cMalwarePath\u003e\" . It then\r\nwaits for 11 seconds ( timeout /t 11 ) before recursively and silently removing the dynamically generated\r\ndirectory \u003cGeneratedFolder\u003e .\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 23 of 28\n\nC2 Communication\r\nAfter looking into it a bit, I’ve discovered that the stealer uses a known technique called “Dead Drop Resolver”,\r\nwhich leverages existing, legitimate external web services to host information that points to additional command\r\nand control (C2) infrastructure. By doing this, malware authors can avoid hardcoding C2 addresses in their\r\nmalware, making detection and takedown efforts more challenging.\r\nI observed that the stealer uses two well-known sites — Steam and Telegram. For those unfamiliar, Steam is a\r\npopular gaming platform where users can purchase thousands of games, while Telegram is a widely used\r\nmessaging platform. Following those URLs reveals the real C2 address in use by the stealer\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 24 of 28\n\nThe addresses are bundled with a hard-coded profile ID (dqu220), which is used to retrieve the correct\r\nconfiguration of the malware.\r\nC2 Data Exfiltration\r\nFrom what it seems, the stealer creates a zip archive where it stores all the relevant files and sends it in a POST\r\nrequest to the C2 server in a base64-encoded format. In the last POST request, the stealer adds additional content\r\nto be sent to the C2 server.\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 25 of 28\n\nSummary\r\nVidar Stealer is a highly versatile malware designed to steal a wide variety of sensitive information. It uses smart\r\ntechniques to avoid hard-coded command-and-control (C2) servers, making it harder to track. On top of that, it\r\ncan act as a downloader, fetching and executing additional malicious payloads.\r\nIndicators Of Compromise (IOC)\r\nIndicators Type Description\r\nfe0d2c8f9e42e9672c51e3f1d478f9398fe88c6f31f83cadbb07d3bb064753c6 SHA256\r\nf2399716df6735c66dfa05a713ff41182e80a6c3c596ecb133b34b65f2d1f00f SHA256\r\ndcc05c3ac7ae22d601bcb7c97cfcda568f3041bd39b2fd8899282dfde83369a5 SHA256\r\n879d835c2156b4d12a5e4d542c282861540c3799225238ff34ffa4b308c376cb SHA256\r\nd2bcc0239e7a272fa47b91a726598fd7ad526d7ca16a3ca3556bfc3db7e3bb81 SHA256\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/vcruntime140[.]dll URL\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/softokn3[.]dll URL\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/nss3[.]dll URL\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/msvcp140[.]dll URL\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/mozglue[.]dll URL\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 26 of 28\n\nIndicators Type Description\r\nhxxp[://]77[.]90[.]153[.]241/a07daa7aeaf96e14/freebl3[.]dll URL\r\nhxxp[://]77[.]90[.]153[.]244/v7942[.]exe URL\r\nhxxps[://]steamcommunity[.]com/profiles/76561199832267488 URL\r\nhxxps[://]t[.]me/g_etcontent URL\r\nhxxps[://]t[.]p[.]formaxprime[.]co[.]uk URL\r\nYara Rules\r\nrule Vidar_stealer {\r\n meta:\r\n description = \"A rule for detecting Vidar stealer malware\"\r\n sha1 = \"689f5c3624a4428e9937ca6a6c26d449dc291a12\"\r\n author = \"AviaB\"\r\n strings:\r\n $mz = \"MZ\"\r\n $B1 = \"steamcommunity.com/profiles/76561199832267488\"\r\n $B2 = \"t.me/g_etcontent\"\r\n $B3 = \"information.txt\"\r\n $B4 = \"passwords.txt\"\r\n $B5 = \"HWID:\"\r\n $B6 = \"MachineID:\"\r\n $B7 = \"GUID:\"\r\n $B8 = \"AV:\"\r\n condition:\r\n ($mz at 0) and 2 of ($B*)\r\n}\r\nPrevious Post Phorpiex Malware Analysis\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 27 of 28\n\nNext Post Breaking Down A Multi-Stage PowerShell Infection\r\nSource: https://aviab1.github.io/blog/vidar-stealer/\r\nhttps://aviab1.github.io/blog/vidar-stealer/\r\nPage 28 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://aviab1.github.io/blog/vidar-stealer/"
	],
	"report_names": [
		"vidar-stealer"
	],
	"threat_actors": [],
	"ts_created_at": 1775434879,
	"ts_updated_at": 1775791275,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f445fa90756c48a153ddc2bbe57a9b633ce6a344.pdf",
		"text": "https://archive.orkl.eu/f445fa90756c48a153ddc2bbe57a9b633ce6a344.txt",
		"img": "https://archive.orkl.eu/f445fa90756c48a153ddc2bbe57a9b633ce6a344.jpg"
	}
}