42959 2010-07-26 01:09:24 -0700 Security meta: investigate cross_fuzz crashes 2013-04-03 13:09:21 -0700 1 1 1 Unclassified Security Security Other PC Windows XP RESOLVED FIXED http://lcamtuf.coredump.cx/cross_fuzz/ InRadar P2 Major --- 43040 43041 43139 43140 43295 43297 43299 43667 43676 43722 43888 44150 44151 44152 44153 45681 45852 46222 46326 46410 46427 46434 57140 1 lcamtuf webkit-security-unassigned abarth ap aroben bthomas cevans darin ddkilzer dumi gazmyaser joepeck jschuh laszlo.gombos sam skylined slewis yong.li.webkit oldest_to_newest 255932 0 lcamtuf 2010-07-26 01:09:24 -0700 Hi folks, This fuzzer tends to crash WebKit nightly within several seconds (r63957): http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_fixed.html The bulk of these crashes are NULL pointers, but I allowed it to run for about 2 hours while collecting crash data, and there seems to be a body of more elusive reads and writes to invalid memory addresses (with a prevalence of about 1 per 100 crashes) that seem exploitable, but will be impossible to track down without these NULL ptrs cleaned up. ap@ proved to be instrumental in tracking down crashes for a related fuzzer, ref_fuzz (https://bugs.webkit.org/show_bug.cgi?id=26824), so cc:ing him here. 256180 1 lcamtuf 2010-07-26 12:45:37 -0700 Just FYI, to help prioritize: my current plan is to publish this fuzzer in approx 60 days (or earlier, if all vendors address the problems sooner). Currently, looks like all the major browsers are affected. 256258 2 cevans 2010-07-26 14:49:26 -0700 @Alexey, how much beer do I need to bribe you to clean this up like you did Michal's ref_fuzz? 256510 3 skylined 2010-07-27 04:28:36 -0700 I've collected some information about crashes and I am opening up bugs to track each crash when I have enough details. 257043 4 sam 2010-07-27 23:18:55 -0700 (In reply to comment #1) > Just FYI, to help prioritize: my current plan is to publish this fuzzer in approx 60 days (or earlier, if all vendors address the problems sooner). > > Currently, looks like all the major browsers are affected. Can you bring this up on webkit-security. That is a much better place for us to discuss timelines. 257073 5 lcamtuf 2010-07-28 02:04:36 -0700 For the record, the most current & reliable version is: http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_final_20100728.html There is substantial logging code in the fuzzer, but disabled for performance reasons; it can probably be diverted to some low-overhead channel to recover additional data. Sadly, the dynamic DOM-crawling behavior of the fuzzer largely rules out the possibility to generate repros in the form of batches of static JS. I am not sure I can simplify this much further. 257108 6 62812 skylined 2010-07-28 04:46:19 -0700 Created attachment 62812 Server to use to log what the fuzzer does. I have implemented a server in Python that can accept XHR requests to log information to a file. With minimal changes, the existing fuzzer can use this to output to a file: - function LOG(message) { + var log_id = new Date().valueOf().toString(16).toUpperCase(); + var log_counter = 0; + + function LOG(message) { + var xhr = new XMLHttpRequest(); + xhr.open('POST', '/logs/' + log_id + '.log?' + log_counter++, false); + xhr.setRequestHeader("Content-Type", "text/plain; charset=UTF-8"); + xhr.send(message); Note that this server was not designed with security in mind: it does allow full R/W access to your file system, so please do not expose it to the intertubes. How to use this: 1) Put a copy of the fuzzer in a local folder. 2) Copy the Python server in the same folder. 3) Update the LOG function in the fuzzer as described above. 4) Optionally modify the settings at the start of the Python server code. 5) Start the Python server. 6) Point your favorite browser to the server. The fuzzer will run as usual, but send the log messages to the server along with a unique ID which is based on the start time of the fuzzer. The server will save the messages in a log file based on the unique ID, so you get a new log each time you run the fuzzer. 257201 7 lcamtuf 2010-07-28 09:33:44 -0700 Keep in mind that there is something like 50,000-100,000 LOG() calls per second if you uncomment all the instances, and probably should be even more to better track references. Replacing this with a mechanism that is some three orders of magnitude slower (XHR) is probably not going to be conductive of getting results in a sane timeframe (at least for the more elusive arbitrary memory access bugs). 257297 8 skylined 2010-07-28 12:46:12 -0700 @mz: I was working under the assumption that any way to log data is better than nothing. We should be able to get some info if we run it for, say, 60 days :) Either way, I got my FuzzFramework port of ref_fuzz updated to work in a similar manner and be more effective at finding bugs. Today it started finding many of the same bugs and producing reduced repros. I'll start filing bugs now :). 257342 9 skylined 2010-07-28 13:48:18 -0700 Here's a list of crashes I found during an earlier run in Chromium. This list is probably not exhaustive; I've found crashes not included in this list with my own port of the fuzzer. Note that I have already found a number of different crashes that are caused by almost the same repro, which seems to imply that they are caused by the same bug in different locations. However, the list is quite long, so I expect we have a lot of bugs to fix. --- Totals --------------------------------------------------------------------- Total runs: 1632 in 47588 seconds. Application crashed 1548 out of 1632 runs Crashes found: 31 * WebCore::v8ValueToWebCoreString ReadAV@NULL (cb89e8eb9c0d203f405c1d6513d14b97) Attempt to read from NULL pointer in WebCore::v8ValueToWebCoreString 1 * WebCore::CSSStyleSelector::SelectorChecker::checkOneSelector ReadAV@NULL (ee1436017020027e7d0af466472ee8a3) Attempt to read from NULL pointer (+0x10) in WebCore::CSSStyleSelector::SelectorChecker::checkOneSelector 1 * WTF::HashTable<...> ReadAV@NULL (0ad97e2f1c02a050003c01b3c6661a98) Attempt to read from NULL pointer (+0x10) in WTF::HashTable<...> 2 * v8::internal::ProfileTree::TraverseDepthFirst<...> ReadAV@NULL (e6dd0db2316d0681041db7df20ab48ef) Attempt to read from NULL pointer (+0x2C) in v8::internal::ProfileTree::TraverseDepthFirst<...> 4 * [unknown] in v8::internal::Heap::UpdateNewSpaceReferenceInExternalStringTableEntry ExecAV@NULL (e04c151252e686bfdc36fe357a9556c4) Security: Attempt to execute non-executable NULL pointer (+0x1F) in [unknown] in v8::internal::Heap::UpdateNewSpaceReferenceInExternalStringTableEntry 14 * WebCore::v8StringToWebCoreString<...> ReadAV@NULL (82c75721458c2d1fce8189ca52cd8701) Attempt to read from NULL pointer in WebCore::v8StringToWebCoreString<...> 30 * [unknown] in v8::internal::SymbolTableCleaner::VisitPointers ExecAV@NULL (c875397782229150cc8e13416ac91a39) Security: Attempt to execute non-executable NULL pointer (+0x1F) in [unknown] in v8::internal::SymbolTableCleaner::VisitPointers 27 * tcmalloc::ThreadCache::FreeList::PopRange ReadAV@NULL (4f2e4263d2cc9083a01e819d73b99a15) Attempt to read from NULL pointer (+0x1FA0) in tcmalloc::ThreadCache::FreeList::PopRange 1 * v8::internal::ExternalTwoByteString::ExternalTwoByteStringGet ReadAV@NULL (7e0dc27afae1303f90f31a7b5be2731c) Attempt to read from NULL pointer (+0x8) in v8::internal::ExternalTwoByteString::ExternalTwoByteStringGet 27 * WebCore::v8StringToWebCoreString<...> ReadAV@NULL (f8422e8b997988240159f083e2806467) Attempt to read from NULL pointer in WebCore::v8StringToWebCoreString<...> 2 * [unknown] in IPC::ChannelProxy::Context::TryFilters ExecAV@NULL (230f5af34b088778e449a311ae7b95b2) Security: Attempt to execute non-executable NULL pointer in [unknown] in IPC::ChannelProxy::Context::TryFilters 1084 * WebCore::CSSStyleSelector::styleForElement ReadAV@NULL (dc7b32067c1b2c657a6337dd1beb1998) Attempt to read from NULL pointer (+0x24) in WebCore::CSSStyleSelector::styleForElement 55 * v8::Value::IsUndefined ReadAV@NULL (46cf324ff4d90096390ce66a8724d8a2) Attempt to read from NULL pointer in v8::Value::IsUndefined 3 * kZerob ExecAV@Arbitrary (4b1acb8b140d549bc5c7757b28cf9713) Security: Attempt to execute non-executable arbitrary memory @ 0x64A68528 in kZerob 2 * [unknown] in WebCore::V8Storage::namedPropertyEnumerator ExecAV@NULL (de39145667a622f56fc4cf25af85441c) Security: Attempt to execute non-executable NULL pointer (+0x1F) in [unknown] in WebCore::V8Storage::namedPropertyEnumerator 11 * v8::internal::ExternalTwoByteString::ExternalTwoByteStringGet ReadAV@NULL (63208b4dfc31329f25be59e71b94da52) Attempt to read from NULL pointer (+0x8) in v8::internal::ExternalTwoByteString::ExternalTwoByteStringGet 40 * tcmalloc::CentralFreeList::RemoveRange ReadAV@NULL (861a4f18fc3c9a208ad77c4a73079962) Attempt to read from NULL pointer (+0x4830) in tcmalloc::CentralFreeList::RemoveRange 2 * std::list<...>::_Tidy ReadAV@NULL (7db290478ddc450ea5eda549e811f84b) Attempt to read from NULL pointer (+0x239E) in std::list<...>::_Tidy 1 * tcmalloc::ThreadCache::FreeList::PopRange ReadAV@NULL (e7f247aaf6305bd98a58b66163f32ecf) Attempt to read from NULL pointer in tcmalloc::ThreadCache::FreeList::PopRange 86 * tcmalloc::ThreadCache::Allocate ReadAV@NULL (916b1b80b0657b01ca62e934c8bfe435) Attempt to read from NULL pointer (+0x6060) in tcmalloc::ThreadCache::Allocate 1 * WTF::HashMap<...>::find ReadAV@NULL (57234c212b70515421f7f0a865c70d63) Attempt to read from NULL pointer (+0x40) in WTF::HashMap<...>::find 1 * WebCore::ResourceHandle::setDefersLoading ReadAV@NULL (964235000062ac871e13770a6f2465db) Attempt to read from NULL pointer (+0x5E4) in WebCore::ResourceHandle::setDefersLoading 1 * WebCore::Frame::settings ReadAV@Arbitrary (f1f252723a8fba1d1ab2d5638719d85c) Security: Attempt to read from arbitrary memory @ 0x1B056606 in WebCore::Frame::settings 48 * WebCore::v8StringToWebCoreString<...> ReadAV@NULL (13d73eadafae4a0e3f3be0f8b67da3b5) Attempt to read from NULL pointer in WebCore::v8StringToWebCoreString<...> 1 * WebCore::ResourceLoader::releaseResources ReadAV@NULL (b41759dd7a44d2220455d8b6133966f7) Attempt to read from NULL pointer in WebCore::ResourceLoader::releaseResources 13 * v8::internal::SymbolTableCleaner::VisitPointers ReadAV@NULL (b18a7578fdd9e438e324ca402e05de54) Attempt to read from NULL pointer (+0x4) in v8::internal::SymbolTableCleaner::VisitPointers 1 * WebCore::AutoTableLayout::recalcColumn ReadAV@NULL (47c4a759037b83d2f9f51ff84aeecef3) Attempt to read from NULL pointer (+0xAF) in WebCore::AutoTableLayout::recalcColumn 3 * [unknown] in WebCore::CSSStyleSelector::applyProperty ExecAV@NULL (976755a6a4943014432368bf55b269fc) Security: Attempt to execute non-executable NULL pointer in [unknown] in WebCore::CSSStyleSelector::applyProperty 3 * tcmalloc::CentralFreeList::FetchFromSpansSafe ReadAV@NULL (25a95c62d87e4e6097c3c1c93a7fcefa) Attempt to read from NULL pointer (+0x1D2C) in tcmalloc::CentralFreeList::FetchFromSpansSafe 1 * v8::internal::ExternalTwoByteString::ExternalTwoByteStringReadBlockIntoBuffer ReadAV@NULL (52da055f45c2cf4cf2cfed5e67a916b4) Attempt to read from NULL pointer (+0x8) in v8::internal::ExternalTwoByteString::ExternalTwoByteStringReadBlockIntoBuffer 1 * webkit_glue::SerializeNPIdentifier ReadAV@NULL (d8225a2aa13e714081e3b7b3879c10f2) Attempt to read from NULL pointer in webkit_glue::SerializeNPIdentifier 4 * v8::internal::Heap::UpdateNewSpaceReferenceInExternalStringTableEntry ReadAV@NULL (d91d2eb1264f5476ad2c929c9091e3e0) Attempt to read from NULL pointer (+0x4) in v8::internal::Heap::UpdateNewSpaceReferenceInExternalStringTableEntry 9 * std::basic_string<...> ReadAV@NULL (b1664ffeee133fe441240d0f384f63cd) Attempt to read from NULL pointer in std::basic_string<...> 1 * WebCore::Chrome::windowRect ReadAV@NULL (83c16086e53c44a806a015b12dbab5a5) Attempt to read from NULL pointer (+0x1760) in WebCore::Chrome::windowRect 1 * [unknown] in WebCore::V8Proxy::runScript ExecAV@Arbitrary (103362849b00f5068909c9bbc1d8faf5) Security: Attempt to execute non-executable arbitrary memory @ 0x00EB45A0 in [unknown] in WebCore::V8Proxy::runScript 1 * `anonymous namespace'::PureCall DebugBreak (318e1cd3ad6ea781d52d6600f83d944d) Debugger breakpoint in `anonymous namespace'::PureCall 1 * WebCore::RenderLayer::paintList ReadAV@NULL (14683c4f4c3756ddb633951de3999428) Attempt to read from NULL pointer in WebCore::RenderLayer::paintList 1 * [unknown] in WebCore::CSSRule::parentStyleSheet ExecAV@Arbitrary (85dce828ec3b4dcd1e8309a8628d368f) Security: Attempt to execute non-executable arbitrary memory @ 0x37353A38 in [unknown] in WebCore::CSSRule::parentStyleSheet 8 * WebCore::CSSStyleSelector::matchRules ReadAV@NULL (ddadcc564002a587b76843cf206b4d62) Attempt to read from NULL pointer (+0x8) in WebCore::CSSStyleSelector::matchRules 14 * v8::internal::ProfilerEventsProcessor::AddCurrentStack ReadAV@NULL (480a56e37d10e09542742ea90abe880c) Attempt to read from NULL pointer (+0x50) in v8::internal::ProfilerEventsProcessor::AddCurrentStack 8 * kZerob ExecAV@Arbitrary (a9ede760a659c2e0e07f2ceaa3e0f871) Security: Attempt to execute non-executable arbitrary memory @ 0x63138528 in kZerob 2 * tcmalloc::ThreadCache::ReleaseToCentralCache ReadAV@NULL (c17ede9be4ef0c35752557d3b9fd0595) Attempt to read from NULL pointer in tcmalloc::ThreadCache::ReleaseToCentralCache 257945 10 lcamtuf 2010-07-29 15:51:44 -0700 New major version. The two most significant changes include randomizing DOM crawl order, and limiting object crawl fanout. http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_randomized_20100729.html It seems to trigger a more varied set of faults, and is less prone to hitting the NULL ptrs. 258733 11 ap 2010-08-01 23:13:27 -0700 <rdar://problem/8260939> 261774 12 abarth 2010-08-07 14:28:44 -0700 https://bugs.webkit.org/show_bug.cgi?id=43677 https://bugs.webkit.org/show_bug.cgi?id=43680 Not marking as blockers because I don't want to link to this bug from non-security bugs. 261775 13 abarth 2010-08-07 14:34:24 -0700 I can't get much more useful out of this fuzzer because I keep hitting Bug 43676. Hopefully dumi can fix that one soon. 262478 14 abarth 2010-08-09 20:35:56 -0700 dumi posted a patch for Bug 43676. He says he ran the fuzzer for a while after that without hitting any other problems. I'll give it another spin at some point. 265959 15 abarth 2010-08-17 23:02:03 -0700 I played with this a bit more and filed a bunch of bugs (some with patches). It found at least one real security bug. I suspect there's more to find here. On my last run, it ran for a while and then locked up in some SVG morphology code that I didn't understand. In any case, I think it would be more productive if other folks started looking at this fuzzer too. 276645 16 lcamtuf 2010-09-09 11:55:41 -0700 OK - not to be annoying, but is there any specific plan to tackle these issues any further at this point? 276676 17 abarth 2010-09-09 12:39:03 -0700 (In reply to comment #16) > OK - not to be annoying, but is there any specific plan to tackle these issues any further at this point? Do you mean w.r.t. the open bugs? The open bugs appear to be a null pointer crash, an assert, a request for a test case, and one nasty crash with zero information about how to reproduce. That seems pretty non-actionable / low-impact to me. If you mean w.r.t. finding new bugs with the fuzzer, I think there's more work to be done there, however. 276679 18 lcamtuf 2010-09-09 12:41:59 -0700 Yes, the latter (unless there are no more exploitable crashes on trunk - in which case, I can verify and close this bug). 276681 19 abarth 2010-09-09 12:44:18 -0700 I think the fuzzer needs more running. As I said in Comment #15, I'd prefer if someone else would give it a spin, but if no one steps up to the plate, it will rise to the top of my list again at some point. 276690 20 jschuh 2010-09-09 13:01:54 -0700 We got a bit delayed on our end, but we'll have it running and outputting reproductions in the next day or so. And we're just going to leave it chugging until it stops finding things. 279301 21 lcamtuf 2010-09-14 18:31:49 -0700 Note that logging *can* be enabled in the original fuzzer very easily, to collect a trace of all executed JS commands. There is some (commented out) code along these lines in place already, which also provides debug information about the DOM crawl status; but the surest and most robust way to do this is just to replace all calls to eval() with calls a logging version. The only downside of this is that: 1) It is infuriatingly slow (but that's better than not making progress at all), 2) The repros will be huge and not necessarily easy to minimize. 279345 22 lcamtuf 2010-09-14 19:44:40 -0700 Here's an untested, but probably close-to-usable version of the fuzzer that passes all the executed JS commands to LOG() - which in turn can be piped to a suitable channel, and with minimal effort, used to recover (probably still very unhelpful) repro cases. The default <textarea> output is painfully slow. Perhaps console.log() is better. http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_randomized_20100729_logging.html Note that cross_fuzz_randomized_20100729.html should remain the canonical test case for confirming there are no outstanding issues. 279352 23 ap 2010-09-14 20:26:11 -0700 The important part is being able to reproduce whatever crash was encountered during a given run. Logging all operations is one way to approach this. Another way is to log pseudo-random number generator seed, and then replay a sequence of subtests - that's what we've been getting from iExploder, for example. There might be other ways that are more appropriate for cross_fuzz. We could even add temporary hooks in local builds for that. 279356 24 lcamtuf 2010-09-14 20:33:07 -0700 Yes, sure; plugging a seed-enabled PRNG into the fuzzer is 2 minutes of work, but in the previous conversations, I had the impression that people are not happy with this alone. 279360 25 lcamtuf 2010-09-14 20:43:11 -0700 Here's a version that does just that: http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_randomized_20100729_seed.html It accepts seed in location.hash, say: http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_randomized_20100729_seed.html#1234 If no seed is found, it picks one based on system time, and updates location.hash accordingly. 280505 26 ap 2010-09-16 19:11:16 -0700 Alas, this doesn't seem to help much for some reason - even with a seed, I'm getting wildly different crashes each time. Logging versions seem to be quite slow indeed, even when using console.log. I've modified JSC to add all eval arguments to a static Vector<UChar*> internally, that seem to work better. 280550 27 lcamtuf 2010-09-16 23:25:43 -0700 The seeded version works reasonably well for me in Chrome, but there is probably some jitter related to document loading times, etc. Do you mean you can never repro anything with the same seed, or that results vary only from time to time? 280557 28 ap 2010-09-16 23:56:41 -0700 In my experience, it seemed like the seed didn't help achieve reproducible results. But it usually takes a minute or two to crash, so there is a lot of time for loading time to affect results. 293119 29 lcamtuf 2010-10-12 14:28:06 -0700 There hasn't been any activity on this bug for a while, so just wanted to check status. Looks like almost all the linked bugs are fixed, but I think there are still some security-relevant crashes in nightly builds? 329803 30 lcamtuf 2011-01-05 14:43:51 -0800 Just FYI, I have made modifications to cross_fuzz that greatly improve the ability to reproduce crashes from a known seed. It's not nearly as good as having clean repros, but it allows you to run cross_fuzz continuously, pick the seed that crashed the soonest, and work from there reproducing at will. To make it work, you need to do the following: 1) wget -r -np the entire http://lcamtuf.coredump.cx/cross_fuzz/ directory to file:/// 2) Set home page for the test profile to about:blank, disable safesearch, auto-updates, and any other mechanisms that may be introducing additional unpredictable latency. Also disable pop-up blocking. 3) Start the browser in incognito mode, allowing JS file:/// access. For Chrome, this is: chrome --incognito --allow-file-access-from-files file:///somewhere/cross_fuzz_randomized_20110105_seed.html#1234 ...where #1234 is your desired seed (pick a 32-bit random integer across fuzzing runs). In Chrome, this yields a very good repro rate. 611074 31 ap 2012-04-26 16:37:03 -0700 We've got a lot of mileage from this, and this bug doesn't appear to be tracking anything practical at this time. Folks of course continue running fuzzers, but there has been no orchestrated effort to fix cross_fuzz crashes in more than two years. Resolved/Fixed. 868869 32 gazmyaser 2013-04-03 13:03:47 -0700 Hi! I added cross _fuzz preservation test pages. Store them in localStorage. When you restart, the last test page in a browser, on which there was a crash, crash does not happen again. Why is that? 868874 33 gazmyaser 2013-04-03 13:09:21 -0700 Hi! I added cross _fuzz preservation test pages. Store them in localStorage. When you restart, the last test page in a browser, on which there was a crash, crash does not happen again. Why is that?(In reply to comment #30) > Just FYI, I have made modifications to cross_fuzz that greatly improve the ability to reproduce crashes from a known seed. It's not nearly as good as having clean repros, but it allows you to run cross_fuzz continuously, pick the seed that crashed the soonest, and work from there reproducing at will. > > To make it work, you need to do the following: > > 1) wget -r -np the entire http://lcamtuf.coredump.cx/cross_fuzz/ directory to file:/// > > 2) Set home page for the test profile to about:blank, disable > safesearch, auto-updates, and any other mechanisms that may be introducing additional unpredictable latency. Also disable pop-up blocking. > > 3) Start the browser in incognito mode, allowing JS file:/// access. For Chrome, this is: > > chrome --incognito --allow-file-access-from-files > file:///somewhere/cross_fuzz_randomized_20110105_seed.html#1234 > > ...where #1234 is your desired seed (pick a 32-bit random integer across fuzzing runs). > > In Chrome, this yields a very good repro rate. 62812 2010-07-28 04:46:19 -0700 2010-07-28 04:46:19 -0700 Server to use to log what the fuzzer does. mini_server.py text/plain 8926 skylined aW1wb3J0IG9zLCByZSwgc29ja2V0LCB0aHJlYWQsIHRocmVhZGluZzsNCg0KIyBTZXR0aW5ncyB0 aGF0IHlvdSBtYXkgd2FudCB0byBjaGFuZ2U6DQpXRUJTRVJWRVJfUE9SVCA9IDI4ODc2Ow0KTE9H U19GT0xERVIgPSBvcy5wYXRoLmpvaW4ob3MuZ2V0Y3dkKCksICdsb2dzJyk7DQpGVVpaRVJfSFRN TCA9ICdjcm9zc19mdXp6X2ZpbmFsXzIwMTAwNzI4Lmh0bWwnOw0KVkVSQk9TRV9PVVRQVVQgPSBU cnVlOw0KDQojIFNldHRpbmdzIHRoYXQgeW91IG1heSBuZWVkIHRvIGNoYW5nZSBpZiB5b3UgYWRk IG5ldyBmaWxlIHR5cGVzOg0KREVGQVVMVF9NSU1FX1RZUEUgPSAnYXBwbGljYXRpb24vb2N0ZXQt c3RyZWFtJzsNClJFR0lTVEVSRURfTUlNRV9UWVBFUyA9IHsNCiAgJ3RleHQvaHRtbCc6IFsnaHRt JywgJ2h0bWwnXSwNCiAgJ3RleHQvamF2YXNjcmlwdCc6IFsnanMnXSwNCiAgJ2ltYWdlL3N2Zyt4 bWwnOiBbJ3N2ZyddLA0KICAnaW1hZ2UvanBlZyc6IFsnanBnJ10sDQp9Ow0KDQpkZWYgTWltZVR5 cGUocGF0aCk6DQogIGxhc3RfZG90ID0gcGF0aC5yZmluZCgnLicpOw0KICBpZiBsYXN0X2RvdCAh PSAtMToNCiAgICBleHQgPSBwYXRoW2xhc3RfZG90ICsgMTpdLmxvd2VyKCk7DQogICAgZm9yIG1p bWVfdHlwZSwgZXh0cyBpbiBSRUdJU1RFUkVEX01JTUVfVFlQRVMuaXRlbXMoKToNCiAgICAgIGlm IGV4dCBpbiBleHRzOg0KICAgICAgICByZXR1cm4gbWltZV90eXBlOw0KICByZXR1cm4gREVGQVVM VF9NSU1FX1RZUEU7DQoNCmRlZiBHZW5lcmF0ZVJlZGlyZWN0KG5ld19wYXRoKToNCiAgcmV0dXJu ICgzMDEsICdNb3ZlZCBwZXJtYW5lbnRseScsIFwNCiAgICAgIFsnTG9jYXRpb246IGh0dHA6Ly9s b2NhbGhvc3Q6JXMlcycgJSAoV0VCU0VSVkVSX1BPUlQsIG5ld19wYXRoKV0sIFwNCiAgICAgICd0 ZXh0L2h0bWwnLCAnPGEgaHJlZj0iJXMiPiVzPC9hPicgJSAobmV3X3BhdGgsIG5ld19wYXRoKSk7 DQoNCmRlZiBSZXBseTQwNChwYXRoLCBxdWVyeSwgZGF0YSk6DQogIHJldHVybiA0MDQsICdOb3Qg Zm91bmQnLCAndGV4dC9wbGFpbicsICdUaGUgcGF0aCAlcyB3YXMgbm90IGZvdW5kJyAlIHBhdGg7 DQoNCmRlZiBSZXBseUZpbGUocGF0aCwgcXVlcnksIGRhdGEpOg0KICBwYXRoID0gb3MucGF0aC5q b2luKG9zLmdldGN3ZCgpLCBwYXRoWzE6XS5yZXBsYWNlKG9zLmFsdHNlcCwgb3Muc2VwKSk7DQog IGlmIG9zLnBhdGguaXNmaWxlKHBhdGgpOg0KICAgIHRyeToNCiAgICAgIGRhdGEgPSBvcGVuKHBh dGgsICdyYicpLnJlYWQoKTsNCiAgICBleGNlcHQ6DQogICAgICBwcmludCAnICAgQ2Fubm90IG9w ZW4gZmlsZSAlcycgJSBwYXRoOw0KICAgICAgcmV0dXJuIDUwMCwgJ0ludGVybmFsIHNlcnZlciBl cnJvcicsICd0ZXh0L3BsYWluJywgXA0KICAgICAgICAgICdUaGUgcGF0aCAlcyBjb3VsZCBub3Qg YmUgcmVhZCcgJSBwYXRoOw0KICAgIGlmIFZFUkJPU0VfT1VUUFVUOg0KICAgICAgcHJpbnQgJyAg IFJlcGx5ID0gZmlsZSAlcycgJSBwYXRoOw0KICAgIHJldHVybiAyMDAsICdPSycsIE1pbWVUeXBl KHBhdGgpLCBkYXRhOw0KICBwcmludCAnICAgQ2Fubm90IGZpbmQgZmlsZSAlcycgJSBwYXRoOw0K ICByZXR1cm4gNDA0LCAnTm90IGZvdW5kJywgJ3RleHQvcGxhaW4nLCAnVGhlIHBhdGggJXMgd2Fz IG5vdCBmb3VuZCcgJSBwYXRoOw0KDQpkZWYgUmVwbHlMb2cocGF0aCwgcXVlcnksIGRhdGEpOg0K ICBwYXRoID0gb3MucGF0aC5qb2luKExPR1NfRk9MREVSLCBwYXRoW2xlbignL2xvZ3MvJyk6XS5y ZXBsYWNlKCcvJywgb3Muc2VwKSk7DQogIHRyeToNCiAgICBvcGVuKHBhdGgsICdhYicpLndyaXRl KGRhdGEgKyAnXHJcbicpOw0KICBleGNlcHQ6DQogICAgcHJpbnQgJyAgIENhbm5vdCB3cml0ZSB0 byBsb2cgZmlsZSAlcycgJSBwYXRoOw0KICAgIHJldHVybiA1MDAsICdJbnRlcm5hbCBzZXJ2ZXIg ZXJyb3InLCAndGV4dC9wbGFpbicsIFwNCiAgICAgICAgJ1RoZSBwYXRoICVzIGNvdWxkIG5vdCBi ZSByZWFkJyAlIHBhdGg7DQogIGlmIFZFUkJPU0VfT1VUUFVUOg0KICAgIHByaW50ICcgICBXcm90 ZSAlcyBieXRlcyB0byBsb2cgZmlsZSAlcycgJSAobGVuKGRhdGEpLCBwYXRoKTsNCiAgcmV0dXJu IDIwMCwgJ09LJywgJ3RleHQvcGxhaW4nLCAnTG9nIHN1Y2Nlc3NmdWwnOw0KICANCiMgUmVwbGll cyBjb250YWlucyBlbnRyaWVzIGluIG9uZSBvZiB0d28gZm9ybXM6DQojICAgICJyZWdleHAiOiAo Im1pbWV0eXBlIiwgImJvZHkiKSwNCiMgICAgInJlZ2V4cCI6IGZ1bmN0aW9uLA0KIyBUaGUgZmly c3QgZm9ybSBjYXVzZXMgdGhlIHNlcnZlciB0byByZXBseSB3aXRoICIyMDAgT0siIGFuZCB0aGUg Z2l2ZW4gYm9keSBhbmQNCiMgbWltZXR5cGUuIFRoZSBzZWNvbmQgZm9ybSByZXF1aXJlcyAiZnVu Y3Rpb24iIHRvIGFjY2VwdCB0aGUgSFRUUCByZXF1ZXN0IHBhdGgNCiMgYXMgYW4gYXJndW1lbnQg YW5kIHJldHVybiBhIHR1cGxlIGNvbnRhaW5pbmcgdGhlIEhUVFAgcmV0dXJuIGNvZGUsIEhUVFAg cmVhc29uDQojIG1lc3NhZ2UsIG1pbWV0eXBlIGFuZCBib2R5Lg0KcmVwbGllcyA9IFsNCiAgKHIn Xi8kJywgICAgICAgIEdlbmVyYXRlUmVkaXJlY3QoJy8nICsgRlVaWkVSX0hUTUwpKSwNCiAgKHIn Xi9sb2dzLy4qJCcsIFJlcGx5TG9nKSwNCiAgKHInXi4qJCcsICAgICAgIFJlcGx5RmlsZSksDQpd Ow0KDQoNCmRlZiBNYWluKCk6DQogIGlmIG5vdCBvcy5wYXRoLmlzZGlyKExPR1NfRk9MREVSKToN CiAgICB0cnk6DQogICAgICBvcy5ta2RpcihMT0dTX0ZPTERFUik7DQogICAgZXhjZXB0Og0KICAg ICAgcHJpbnQgJ0Nhbm5vdCBjcmVhdGUgbG9ncyBmb2xkZXIgJXMnICUgTE9HU19GT0xERVI7DQog ICAgICByZXR1cm47DQogIHNlcnZlcl9zb2NrZXQgPSBzb2NrZXQuc29ja2V0KCk7DQogIHNlcnZl cl9zb2NrZXQuc2V0c29ja29wdChzb2NrZXQuU09MX1NPQ0tFVCwgc29ja2V0LlNPX1JFVVNFQURE UiwgMSk7DQogIHNlcnZlcl9zb2NrZXQuYmluZCgoJycsIFdFQlNFUlZFUl9QT1JUKSk7DQogIHNl cnZlcl9zb2NrZXQubGlzdGVuKDEpOw0KICBwcmludCAnV2Vic2VydmVyIHJ1bm5pbmcgYXQgaHR0 cDovL2xvY2FsaG9zdDolZC8nICUgV0VCU0VSVkVSX1BPUlQ7DQogIHByaW50Ow0KICB0aHJlYWRf Y291bnRlciA9IDA7DQogIHdoaWxlIDE6DQogICAgY2xpZW50X3NvY2tldCwgY2xpZW50X2FkZHJl c3MgPSBzZXJ2ZXJfc29ja2V0LmFjY2VwdCgpOw0KICAgIHRocmVhZCA9IHRocmVhZGluZy5UaHJl YWQodGFyZ2V0ID0gQ29ubmVjdGlvblRocmVhZCwgXA0KICAgICAgICBhcmdzID0gKGNsaWVudF9z b2NrZXQsIGNsaWVudF9hZGRyZXNzKSk7DQogICAgdGhyZWFkLnN0YXJ0KCk7DQogICAgdGhyZWFk X2NvdW50ZXIgKz0gMTsNCg0KZGVmIENvbm5lY3Rpb25UaHJlYWQoY2xpZW50X3NvY2tldCwgY2xp ZW50X2FkZHJlc3MpOg0KICB0cnk6DQogICAgcHJpbnQgJyoqIENvbm5lY3Rpb24gZnJvbSAlczol cyBvcGVuZWQuJyAlIGNsaWVudF9hZGRyZXNzOw0KICAgIHdoaWxlIDE6DQogICAgICB0cnk6DQog ICAgICAgIHJlcXVlc3RfaGVhZGVycywgcmVxdWVzdF9jb250ZW50ID0gUmVhZFJlcXVlc3QoY2xp ZW50X3NvY2tldCk7DQogICAgICAgIGlmIHJlcXVlc3RfaGVhZGVycyBpcyBOb25lOg0KICAgICAg ICAgIGJyZWFrOw0KICAgICAgICByZXNwb25zZSA9IEhhbmRsZVJlcXVlc3QocmVxdWVzdF9oZWFk ZXJzLCByZXF1ZXN0X2NvbnRlbnQpOw0KICAgICAgICB0cnk6DQogICAgICAgICAgY2xpZW50X3Nv Y2tldC5zZW5kKHJlc3BvbnNlKTsNCiAgICAgICAgZXhjZXB0IHNvY2tldC5lcnJvciwgZToNCiAg ICAgICAgICByYWlzZSBDb25uZWN0aW9uRXJyb3IoJ0Nhbm5vdCBzZW5kIHJlc3BvbnNlJyk7DQog ICAgICBleGNlcHQgQ29ubmVjdGlvbkVycm9yLCBlOg0KICAgICAgICBwcmludCAnICAgQ29ubmVj dGlvbkVycm9yOiAlcycgJSBlOw0KICAgICAgICB0cnk6DQogICAgICAgICAgY2xpZW50X3NvY2tl dC5jbG9zZSgpOw0KICAgICAgICBleGNlcHQ6DQogICAgICAgICAgcGFzczsNCiAgICAgICAgYnJl YWs7DQogICAgcHJpbnQgJyoqIENvbm5lY3Rpb24gZnJvbSAlczolcyBjbG9zZWQnICUgY2xpZW50 X2FkZHJlc3M7DQogIGV4Y2VwdDoNCiAgICB0aHJlYWQuaW50ZXJydXB0X21haW4oKTsNCg0KY2xh c3MgQ29ubmVjdGlvbkVycm9yKEV4Y2VwdGlvbik6DQogIGRlZiBfX2luaXRfXyhzZWxmLCB2YWx1 ZSk6DQogICAgc2VsZi52YWx1ZSA9IHZhbHVlOw0KICBkZWYgX19zdHJfXyhzZWxmKToNCiAgICBy ZXR1cm4gc2VsZi52YWx1ZTsNCg0KZGVmIEdldENvbnRlbnRMZW5ndGgocmVxdWVzdF9oZWFkZXJz KToNCiAgZm9yIHJlcXVlc3RfaGVhZGVyIGluIHJlcXVlc3RfaGVhZGVyczoNCiAgICBpZiByZXF1 ZXN0X2hlYWRlci5maW5kKCc6JykgIT0gLTE6DQogICAgICBuYW1lLCB2YWx1ZSA9IHJlcXVlc3Rf aGVhZGVyLnNwbGl0KCc6JywgMSk7DQogICAgICBpZiBuYW1lLnN0cmlwKCkubG93ZXIoKSA9PSAn Y29udGVudC1sZW5ndGgnOg0KICAgICAgICB0cnk6DQogICAgICAgICAgcmV0dXJuIGludCh2YWx1 ZSk7DQogICAgICAgIGV4Y2VwdCBWYWx1ZUVycm9yOg0KICAgICAgICAgIHJhaXNlIENvbm5lY3Rp b25FcnJvcignQmFkIGNvbnRlbnQtbGVuZ3RoIHZhbHVlOiAlcycgJSB2YWx1ZSk7DQogIHJldHVy biBOb25lOw0KDQpkZWYgUmVhZFJlcXVlc3QoY2xpZW50X3NvY2tldCk6DQogIHJlcXVlc3QgPSAn JzsNCiAgcmVxdWVzdF9oZWFkZXJzID0gTm9uZTsNCiAgcmVxdWVzdF9oZWFkZXJzX2xlbmd0aCA9 IE5vbmU7DQogIGlmIFZFUkJPU0VfT1VUUFVUOg0KICAgIHByaW50ICc+PiBBY2NlcHRlZCByZXF1 ZXN0LCByZWFkaW5nIGhlYWRlcnMuLi4nLDsNCiAgd2hpbGUgcmVxdWVzdF9oZWFkZXJzIGlzIE5v bmU6DQogICAgdHJ5Og0KICAgICAgcmVxdWVzdCArPSBjbGllbnRfc29ja2V0LnJlY3YoMjU2KTsN CiAgICBleGNlcHQgc29ja2V0LmVycm9yLCBlOg0KICAgICAgaWYgVkVSQk9TRV9PVVRQVVQ6DQog ICAgICAgIHByaW50Ow0KICAgICAgcmFpc2UgQ29ubmVjdGlvbkVycm9yKCdDb25uZWN0aW9uIGRy b3BwZWQgd2hpbGUgcmVhZGluZyByZXF1ZXN0IGhlYWRlcnMuJyk7DQogICAgaWYgbGVuKHJlcXVl c3QpID09IDA6DQogICAgICBpZiBWRVJCT1NFX09VVFBVVDoNCiAgICAgICAgcHJpbnQ7DQogICAg ICAjIHJhaXNlIENvbm5lY3Rpb25FcnJvcignQ29ubmVjdGlvbiBjbG9zZWQuJyk7DQogICAgICBy ZXR1cm4gTm9uZSwgTm9uZTsNCiAgICByZXF1ZXN0X2hlYWRlcnNfbGVuZ3RoID0gcmVxdWVzdC5m aW5kKCdcclxuXHJcbicpOw0KICAgIGlmIHJlcXVlc3RfaGVhZGVyc19sZW5ndGggIT0gLTE6DQog ICAgICByZXF1ZXN0X2hlYWRlcnMgPSByZXF1ZXN0WzpyZXF1ZXN0X2hlYWRlcnNfbGVuZ3RoXS5z cGxpdCgnXHJcbicpWzotMV07DQogICAgICAjIE9uZSBsaW5lIGJyZWFrcyBpcyBwYXJ0IG9mIHRo ZSBoZWFkZXJzDQogICAgICByZXF1ZXN0X2hlYWRlcnNfbGVuZ3RoICs9IDI7DQogICAgICAjIFRo ZSBvdGhlciBpcyBub3QgcGFydCBvZiB0aGUgaGVhZGVycyBvciB0aGUgY29udGVudDoNCiAgICAg IHJlcXVlc3RfY29udGVudF9sZW5ndGggPSBHZXRDb250ZW50TGVuZ3RoKHJlcXVlc3RfaGVhZGVy cyk7DQogICAgICBpZiByZXF1ZXN0X2NvbnRlbnRfbGVuZ3RoIGlzIE5vbmU6DQogICAgICAgIGlm IFZFUkJPU0VfT1VUUFVUOg0KICAgICAgICAgIHByaW50ICdccj4+IEFjY2VwdGVkIHJlcXVlc3Qs IHJlYWQgJWQgYnl0ZXMgb2YgaGVhZGVycyBhbmQgJyBcDQogICAgICAgICAgICAnbm8gY29udGVu dC4nICUgKHJlcXVlc3RfaGVhZGVyc19sZW5ndGgpOw0KICAgICAgICByZXR1cm4gcmVxdWVzdF9o ZWFkZXJzLCBOb25lOw0KICAgICAgcmVxdWVzdF9jb250ZW50ID0gcmVxdWVzdFtyZXF1ZXN0X2hl YWRlcnNfbGVuZ3RoICsgMjpdOw0KICAgIGVsc2U6DQogICAgICBpZiBWRVJCT1NFX09VVFBVVDoN CiAgICAgICAgcHJpbnQgJ1xyPj4gQWNjZXB0ZWQgcmVxdWVzdCwgcmVhZCAlZCBieXRlcyBvZiBo ZWFkZXJzLi4uJyAlIFwNCiAgICAgICAgICAgIGxlbihyZXF1ZXN0KSw7DQoNCiAgd2hpbGUgbGVu KHJlcXVlc3RfY29udGVudCkgPCByZXF1ZXN0X2NvbnRlbnRfbGVuZ3RoOg0KICAgIGlmIFZFUkJP U0VfT1VUUFVUOg0KICAgICAgcHJpbnQgJ1xyPj4gQWNjZXB0ZWQgcmVxdWVzdCwgcmVhZCAlZCBi eXRlcyBvZiBoZWFkZXJzIGFuZCAnIFwNCiAgICAgICAgJyVkLyVkIGJ5dGVzIG9mIGNvbnRlbnQu Li4nICUgKHJlcXVlc3RfaGVhZGVyc19sZW5ndGgsIFwNCiAgICAgICAgbGVuKHJlcXVlc3RfY29u dGVudCksIHJlcXVlc3RfY29udGVudF9sZW5ndGgpLDsNCiAgICByZWFkX3NpemUgPSByZXF1ZXN0 X2NvbnRlbnRfbGVuZ3RoIC0gbGVuKHJlcXVlc3RfY29udGVudCk7DQogICAgdHJ5Og0KICAgICAg cmVxdWVzdF9jb250ZW50ICs9IGNsaWVudF9zb2NrZXQucmVjdihyZWFkX3NpemUpOw0KICAgIGV4 Y2VwdCBzb2NrZXQuZXJyb3IsIGU6DQogICAgICBpZiBWRVJCT1NFX09VVFBVVDoNCiAgICAgICAg cHJpbnQ7DQogICAgICByYWlzZSBDb25uZWN0aW9uRXJyb3IoJ0Nvbm5lY3Rpb24gZHJvcHBlZCB3 aGlsZSByZWFkaW5nIHJlcXVlc3QgY29udGVudC4nKTsNCiAgaWYgVkVSQk9TRV9PVVRQVVQ6DQog ICAgcHJpbnQgJ1xyPj4gQWNjZXB0ZWQgcmVxdWVzdCwgcmVhZCAlZCBieXRlcyBvZiBoZWFkZXJz IGFuZCAnIFwNCiAgICAgICclZCBieXRlcyBvZiBjb250ZW50LiAgJXMnICUgKHJlcXVlc3RfaGVh ZGVyc19sZW5ndGgsIFwNCiAgICAgIGxlbihyZXF1ZXN0X2NvbnRlbnQpLCAnICcgKiBsZW4oc3Ry KHJlcXVlc3RfY29udGVudF9sZW5ndGgpKSk7DQogIHJldHVybiByZXF1ZXN0X2hlYWRlcnMsIHJl cXVlc3RfY29udGVudDsNCg0KZGVmIEhhbmRsZVJlcXVlc3QocmVxdWVzdF9oZWFkZXJzLCByZXF1 ZXN0X2NvbnRlbnQpOg0KICBlbmRfbWV0aG9kID0gcmVxdWVzdF9oZWFkZXJzWzBdLmZpbmQoJyAn KTsNCiAgaWYgZW5kX21ldGhvZCA9PSAtMToNCiAgICByYWlzZSBDb25uZWN0aW9uRXJyb3IoJ0Jh ZCByZXF1ZXN0IGhlYWRlcjsgbm8gbWV0aG9kIHJlY29nbml6ZWQnKTsNCiAgbWV0aG9kID0gcmVx dWVzdF9oZWFkZXJzWzBdWzplbmRfbWV0aG9kXTsNCiAgZW5kX3BhdGggPSByZXF1ZXN0X2hlYWRl cnNbMF0uZmluZCgnICcsIGVuZF9tZXRob2QgKyAxKTsNCiAgaWYgZW5kX3BhdGggPT0gLTE6DQog ICAgcmFpc2UgQ29ubmVjdGlvbkVycm9yKCdCYWQgcmVxdWVzdCBoZWFkZXI7IG5vIHBhdGggcmVj b2duaXplZCcpOw0KICBwYXRoID0gcmVxdWVzdF9oZWFkZXJzWzBdW2VuZF9tZXRob2QgKyAxOmVu ZF9wYXRoXTsNCiAgcXVlcnkgPSBOb25lOw0KICBzdGFydF9xdWVyeSA9IHBhdGguZmluZCgnPycp Ow0KICBpZiBzdGFydF9xdWVyeSAhPSAtMToNCiAgICBxdWVyeSA9IHBhdGhbc3RhcnRfcXVlcnk6 XTsNCiAgICBwYXRoID0gcGF0aFs6c3RhcnRfcXVlcnldOw0KICBpZiBWRVJCT1NFX09VVFBVVDoN CiAgICBwcmludCAnICAgbWV0aG9kPSVzLCBwYXRoPSVzLCBxdWVyeT0lcywgJXMgaGVhZGVycycg JSBcDQogICAgICAobWV0aG9kLCBwYXRoLCBxdWVyeSwgbGVuKHJlcXVlc3RfaGVhZGVycykpOw0K ICBjb2RlLCByZWFzb24sIG1pbWVfdHlwZSwgYm9keSA9IDQwNCwgJ05vdCBmb3VuZCcsICd0ZXh0 L3BsYWluJywgJ05vdCBmb3VuZCc7DQogIHJlc3BvbnNlID0gTm9uZTsNCiAgZm9yIHBhdGhfcmVn ZXhwLCByZXNwb25zZSBpbiByZXBsaWVzOg0KICAgIGlmIHJlLm1hdGNoKHBhdGhfcmVnZXhwLCBw YXRoKToNCiAgICAgIGlmIHR5cGUocmVzcG9uc2UpICE9IHR1cGxlOg0KICAgICAgICByZXNwb25z ZSA9IHJlc3BvbnNlKHBhdGgsIHF1ZXJ5LCByZXF1ZXN0X2NvbnRlbnQpOw0KICAgICAgYnJlYWs7 DQogIGFzc2VydCB0eXBlKHJlc3BvbnNlKSA9PSB0dXBsZSBhbmQgbGVuKHJlc3BvbnNlKSBpbiBb MiwgNCwgNV0sIFwNCiAgICAgICdJbnZhbGlkIHJlc3BvbnNlIHR1cGxlICVzJyAlIHJlcHIocmVz cG9uc2UpOw0KICBjb2RlLCByZWFzb24sIGhlYWRlcnMsIG1pbWVfdHlwZSwgYm9keSA9IDIwMCwg J09LJywgW10sICd0ZXh0L3BsYWluJywgJyc7DQogIGlmIGxlbihyZXNwb25zZSkgPT0gMjoNCiAg ICBtaW1lX3R5cGUsIGJvZHkgPSByZXNwb25zZTsNCiAgZWxpZiBsZW4ocmVzcG9uc2UpID09IDQ6 DQogICAgY29kZSwgcmVhc29uLCBtaW1lX3R5cGUsIGJvZHkgPSByZXNwb25zZTsNCiAgZWxzZToN CiAgICBjb2RlLCByZWFzb24sIGhlYWRlcnMsIG1pbWVfdHlwZSwgYm9keSA9IHJlc3BvbnNlOw0K ICByZXNwb25zZV9saW5lcyA9IFsNCiAgICAnSFRUUC8xLjEgJTAzZCAlcycgJSAoY29kZSwgcmVh c29uKSwNCiAgICAnQ29udGVudC1UeXBlOiAlcycgJSBtaW1lX3R5cGUsDQogICAgJ0RhdGU6IFNh dCBBdWcgMjggMTk3NiAwOToxNTowMCBHTVQnLA0KICAgICdFeHBpcmVzOiBTYXQgQXVnIDI4IDE5 NzYgMDk6MTU6MDAgR01UJywNCiAgICAnQ2FjaGUtQ29udHJvbDogbm8tY2FjaGUsIG11c3QtcmV2 YWxpZGF0ZScsDQogICAgJ1ByYWdtYTogbm8tY2FjaGUnLCANCiAgICAnQWNjZXB0LVJhbmdlczog Ynl0ZXMnLA0KICAgICdDb250ZW50LUxlbmd0aDogJWQnICUgbGVuKGJvZHkpLA0KICBdICsgaGVh ZGVycyArIFsNCiAgICAnJywNCiAgICBib2R5DQogIF07DQogIHJlc3BvbnNlID0gJ1xyXG4nLmpv aW4ocmVzcG9uc2VfbGluZXMpOw0KICBpZiBWRVJCT1NFX09VVFBVVDoNCiAgICBwcmludCAnPDwg JXMgKCVkIGJ5dGVzICVzKScgJSBcDQogICAgICAocmVzcG9uc2Uuc3BsaXQoJ1xyXG4nKVswXSwg bGVuKHJlc3BvbnNlKSwgbWltZV90eXBlKTsNCiAgcmV0dXJuIHJlc3BvbnNlOw0KDQppZiBfX25h bWVfXyA9PSAiX19tYWluX18iOg0KICBNYWluKCk7DQogIA==