CINXE.COM

<!DOCTYPE html> <html class='v2' dir='ltr' lang='en' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'> <head> <link href='https://www.blogger.com/static/v1/widgets/3566091532-css_bundle_v2.css' rel='stylesheet' type='text/css'/> <meta content='width=1100' name='viewport'/> <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'/> <meta content='blogger' name='generator'/> <link href='https://googleprojectzero.blogspot.com/favicon.ico' rel='icon' type='image/x-icon'/> <link href='https://googleprojectzero.blogspot.com/2022/06/' rel='canonical'/> <link rel="alternate" type="application/atom+xml" title="Project Zero - Atom" href="https://googleprojectzero.blogspot.com/feeds/posts/default" /> <link rel="alternate" type="application/rss+xml" title="Project Zero - RSS" href="https://googleprojectzero.blogspot.com/feeds/posts/default?alt=rss" /> <link rel="service.post" type="application/atom+xml" title="Project Zero - Atom" href="https://www.blogger.com/feeds/4838136820032157985/posts/default" />  <meta content='https://googleprojectzero.blogspot.com/2022/06/' property='og:url'/> <meta content='Project Zero' property='og:title'/> <meta content='News and updates from the Project Zero team at Google' property='og:description'/> <title>Project Zero: June 2022</title> <style type='text/css'>@font-face{font-family:'Open Sans';font-style:normal;font-weight:400;font-stretch:normal;font-display:swap;src:url(//fonts.gstatic.com/s/opensans/v40/memSYaGs126MiZpBA-UvWbX2vVnXBbObj2OVZyOOSr4dVJWUgsjZ0B4gaVY.eot);}</style> <style id='page-skin-1' type='text/css'></style> <style id='template-skin-1' type='text/css'></style> <script type='text/javascript'> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','https://www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-240546891-1', 'auto', 'blogger'); ga('blogger.send', 'pageview'); </script> <link href='https://www.blogger.com/dyn-css/authorization.css?targetBlogID=4838136820032157985&zx=9e014bfb-e50c-4ece-bb2f-ed942adb173a' media='none' onload='if(media!='all')media='all'' rel='stylesheet'/><noscript><link href='https://www.blogger.com/dyn-css/authorization.css?targetBlogID=4838136820032157985&zx=9e014bfb-e50c-4ece-bb2f-ed942adb173a' rel='stylesheet'/></noscript> <meta name='google-adsense-platform-account' content='ca-host-pub-1556223355139109'/> <meta name='google-adsense-platform-domain' content='blogspot.com'/> </head> <body class='loading'> <div class='navbar section' id='navbar' name='Navbar'><div class='widget Navbar' data-version='1' id='Navbar1'><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/platform.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar/4838136820032157985?origin\x3dhttps://googleprojectzero.blogspot.com', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script><script type="text/javascript"> (function() { var script = document.createElement('script'); script.type = 'text/javascript'; script.src = '//pagead2.googlesyndication.com/pagead/js/google_top_exp.js'; var head = document.getElementsByTagName('head')[0]; if (head) { head.appendChild(script); }})(); </script> </div></div> <div class='body-fauxcolumns'> <div class='fauxcolumn-outer body-fauxcolumn-outer'> <div class='cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left'> <div class='fauxborder-right'></div> <div class='fauxcolumn-inner'> </div> </div> <div class='cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> </div> <div class='content'> <div class='content-fauxcolumns'> <div class='fauxcolumn-outer content-fauxcolumn-outer'> <div class='cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left'> <div class='fauxborder-right'></div> <div class='fauxcolumn-inner'> </div> </div> <div class='cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> </div> <div class='content-outer'> <div class='content-cap-top cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left content-fauxborder-left'> <div class='fauxborder-right content-fauxborder-right'></div> <div class='content-inner'> <header> <div class='header-outer'> <div class='header-cap-top cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left header-fauxborder-left'> <div class='fauxborder-right header-fauxborder-right'></div> <div class='region-inner header-inner'> <div class='header section' id='header' name='Header'><div class='widget Header' data-version='1' id='Header1'> <div id='header-inner'> <div class='titlewrapper'> <h1 class='title'> <a href='https://googleprojectzero.blogspot.com/'> Project Zero </a> </h1> </div> <div class='descriptionwrapper'> News and updates from the Project Zero team at Google </div> </div> </div></div> </div> </div> <div class='header-cap-bottom cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> </header> <div class='tabs-outer'> <div class='tabs-cap-top cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left tabs-fauxborder-left'> <div class='fauxborder-right tabs-fauxborder-right'></div> <div class='region-inner tabs-inner'> <div class='tabs no-items section' id='crosscol' name='Cross-Column'></div> <div class='tabs no-items section' id='crosscol-overflow' name='Cross-Column 2'></div> </div> </div> <div class='tabs-cap-bottom cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> <div class='main-outer'> <div class='main-cap-top cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left main-fauxborder-left'> <div class='fauxborder-right main-fauxborder-right'></div> <div class='region-inner main-inner'> <div class='columns fauxcolumns'> <div class='fauxcolumn-outer fauxcolumn-center-outer'> <div class='cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left'> <div class='fauxborder-right'></div> <div class='fauxcolumn-inner'> </div> </div> <div class='cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> <div class='fauxcolumn-outer fauxcolumn-left-outer'> <div class='cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left'> <div class='fauxborder-right'></div> <div class='fauxcolumn-inner'> </div> </div> <div class='cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> <div class='fauxcolumn-outer fauxcolumn-right-outer'> <div class='cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left'> <div class='fauxborder-right'></div> <div class='fauxcolumn-inner'> </div> </div> <div class='cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div>  <div class='columns-inner'> <div class='column-center-outer'> <div class='column-center-inner'> <div class='main section' id='main' name='Main'><div class='widget Blog' data-version='1' id='Blog1'> <div class='blog-posts hfeed'> <div class="date-outer"> <h2 class='date-header'>Thursday, June 30, 2022</h2> <div class="date-posts"> <div class='post-outer'> <div class='post hentry uncustomized-post-template' itemprop='blogPost' itemscope='itemscope' itemtype='http://schema.org/BlogPosting'> <meta content='4838136820032157985' itemprop='blogId'/> <meta content='256978548158816980' itemprop='postId'/> <a name='256978548158816980'></a> <h3 class='post-title entry-title' itemprop='name'> <a href='https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html'>2022 0-day In-the-Wild Exploitation…so far</a> </h3> <div class='post-header'> <div class='post-header-line-1'></div> </div> <div class='post-body entry-content' id='post-body-256978548158816980' itemprop='description articleBody'> <style type="text/css">ul.lst-kix_68660h7uawx-0{list-style-type:none}ul.lst-kix_68660h7uawx-1{list-style-type:none}ul.lst-kix_68660h7uawx-2{list-style-type:none}ul.lst-kix_68660h7uawx-3{list-style-type:none}ul.lst-kix_68660h7uawx-4{list-style-type:none}ul.lst-kix_68660h7uawx-5{list-style-type:none}ul.lst-kix_68660h7uawx-6{list-style-type:none}.lst-kix_68660h7uawx-7>li:before{content:"\0025cb "}ul.lst-kix_68660h7uawx-7{list-style-type:none}ul.lst-kix_68660h7uawx-8{list-style-type:none}.lst-kix_68660h7uawx-0>li:before{content:"\0025cf "}.lst-kix_68660h7uawx-6>li:before{content:"\0025cf "}.lst-kix_68660h7uawx-8>li:before{content:"\0025a0 "}li.li-bullet-0:before{margin-left:-18pt;white-space:nowrap;display:inline-block;min-width:18pt}.lst-kix_68660h7uawx-3>li:before{content:"\0025cf "}.lst-kix_68660h7uawx-2>li:before{content:"\0025a0 "}.lst-kix_68660h7uawx-4>li:before{content:"\0025cb "}.lst-kix_68660h7uawx-1>li:before{content:"\0025cb "}.lst-kix_68660h7uawx-5>li:before{content:"\0025a0 "}ol{margin:0;padding:0}table td,table th{padding:0}.HZWKYxoXby-c2{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:156.8pt;border-top-color:#000000;border-bottom-style:solid}.HZWKYxoXby-c9{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:155.2pt;border-top-color:#000000;border-bottom-style:solid}.HZWKYxoXby-c3{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#000000;border-top-width:1pt;border-right-width:1pt;border-left-color:#000000;vertical-align:top;border-right-color:#000000;border-left-width:1pt;border-top-style:solid;border-left-style:solid;border-bottom-width:1pt;width:156pt;border-top-color:#000000;border-bottom-style:solid}.HZWKYxoXby-c19{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:8pt;font-family:"Arial";font-style:normal}.HZWKYxoXby-c15{color:#000000;font-weight:700;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.HZWKYxoXby-c5{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial";font-style:normal}.HZWKYxoXby-c4{padding-top:0pt;padding-bottom:0pt;line-height:1.5;orphans:2;widows:2;text-align:left;height:11pt}.HZWKYxoXby-c6{padding-top:0pt;padding-bottom:0pt;line-height:1.5;orphans:2;widows:2;text-align:left}.HZWKYxoXby-c12{color:#000000;font-weight:400;text-decoration:none;vertical-align:baseline;font-size:11pt;font-family:"Arial"}.HZWKYxoXby-c17{border-spacing:0;border-collapse:collapse;margin-right:auto}.HZWKYxoXby-c0{padding-top:0pt;padding-bottom:0pt;line-height:1.0;text-align:left}.HZWKYxoXby-c1{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}.HZWKYxoXby-c14{background-color:#ffffff;max-width:468pt;padding:72pt 72pt 72pt 72pt}.HZWKYxoXby-c18{margin-left:36pt;padding-left:0pt}.HZWKYxoXby-c8{color:inherit;text-decoration:inherit}.HZWKYxoXby-c13{padding:0;margin:0}.HZWKYxoXby-c21{font-weight:700}.HZWKYxoXby-c7{height:0pt}.HZWKYxoXby-c20{margin-left:36pt}.HZWKYxoXby-c11{height:11pt}.HZWKYxoXby-c16{margin-left:72pt}.HZWKYxoXby-c10{font-style:italic}.title{padding-top:0pt;color:#000000;font-size:26pt;padding-bottom:3pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}.subtitle{padding-top:0pt;color:#666666;font-size:15pt;padding-bottom:16pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}li{color:#000000;font-size:11pt;font-family:"Arial"}p{margin:0;color:#000000;font-size:11pt;font-family:"Arial"}h1{padding-top:20pt;color:#000000;font-size:20pt;padding-bottom:6pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h2{padding-top:18pt;color:#000000;font-size:16pt;padding-bottom:6pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h3{padding-top:16pt;color:#434343;font-size:14pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h4{padding-top:14pt;color:#666666;font-size:12pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h5{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h6{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;font-style:italic;orphans:2;widows:2;text-align:left}</style></head><body class="c14 doc-content"> Posted by Maddie Stone, Google Project Zero This blog post is an overview of a talk, “ 0-day In-the-Wild Exploitation in 2022…so far”, that I gave at the FIRST conference in June 2022. The slides are available <a class="HZWKYxoXby-c81" href="https://github.com/maddiestone/ConPresentations/blob/master/FIRST2022.2022_0days_so_far.pdf">here</a>. For the last three years, we’ve published annual year-in-review reports of 0-days found exploited in the wild. The most recent of these reports is the <a class="HZWKYxoXby-c81" href="https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html">2021 Year in Review report</a>, which we published just a few months ago in April. While we plan to stick with that annual cadence, we’re publishing a little bonus report today looking at the in-the-wild 0-days detected and disclosed in the first half of 2022.         As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022. When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests. On top of that, four of the 2022 0-days are variants of 2021 in-the-wild 0-days. Just 12 months from the original in-the-wild 0-day being patched, attackers came back with a variant of the original bug.   <a id="t.4fab798cceb7e37dcf71e15c259bff9761363678"></a><a id="t.0"></a><table class="HZWKYxoXby-c17"><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Product</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> 2022 ITW 0-day</td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> Variant</td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Windows win32k</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-21882.html">CVE-2022-21882</a></td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html">CVE-2021-1732</a> (2021 itw)</td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> iOS IOMobileFrameBuffer</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://support.apple.com/en-us/HT213053">CVE-2022-22587</a></td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html">CVE-2021-30983</a> (2021 itw)</td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Windows</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30190">CVE-2022-30190</a> (“Follina”)</td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444">CVE-2021-40444</a> (2021 itw)</td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Chromium property access interceptors</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_25.html">CVE-2022-1096</a></td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://bugs.chromium.org/p/chromium/issues/detail?id=619166">CVE-2016-5128</a> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30551.html">CVE-2021-30551</a> (2021 itw) <a class="HZWKYxoXby-c81" href="https://bugs.chromium.org/p/project-zero/issues/detail?id=2280">CVE-2022-1232</a> (Addresses incomplete CVE-2022-1096 fix)</td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Chromium v8</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://chromereleases.googleblog.com/2022/04/stable-channel-update-for-desktop_14.html">CVE-2022-1364</a></td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_30.html">CVE-2021-21195</a></td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> WebKit</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-22620.html">CVE-2022-22620</a> (“Zombie”)</td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html">Bug was originally fixed in 2013, patch was regressed in 2016</a></td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Google Pixel</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://source.android.com/security/bulletin/pixel/2022-03-01">CVE-2021-39793</a>* * While this CVE says 2021, the bug was patched and disclosed in 2022</td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd5297b0855f17c8b4e3ef1d20c6a3656209c7b3">Linux same bug in a different subsystem</a></td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Atlassian Confluence</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html">CVE-2022-26134</a></td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://confluence.atlassian.com/doc/confluence-security-advisory-2021-08-25-1077906215.html">CVE-2021-26084</a></td></tr><tr class="HZWKYxoXby-c7"><td class="HZWKYxoXby-c9" colspan="1" rowspan="1"> Windows</td><td class="HZWKYxoXby-c2" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26925">CVE-2022-26925</a> (“PetitPotam”)</td><td class="HZWKYxoXby-c3" colspan="1" rowspan="1"> <a class="HZWKYxoXby-c81" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36942">CVE-2021-36942</a> (Patch regressed)</td></tr></table> So, what does this mean? When people think of 0-day exploits, they often think that these exploits are so technologically advanced that there’s no hope to catch and prevent them. The data paints a different picture. At least half of the 0-days we’ve seen so far this year are closely related to bugs we’ve seen before. Our conclusion and findings in the <a class="HZWKYxoXby-c81" href="https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html">2020 year-in-review report</a> were very similar. Many of the 2022 in-the-wild 0-days are due to the previous vulnerability not being fully patched. In the case of the Windows win32k and the Chromium property access interceptor bugs, the execution flow that the proof-of-concept exploits took were patched, but the root cause issue was not addressed: attackers were able to come back and trigger the original vulnerability through a different path. And in the case of the WebKit and Windows PetitPotam issues, the original vulnerability had previously been patched, but at some point regressed so that attackers could exploit the same vulnerability again. In the iOS IOMobileFrameBuffer bug, a buffer overflow was addressed by checking that a size was less than a certain number, but it didn’t check a minimum bound on that size. For more detailed explanations of three of the 0-days and how they relate to their variants, please see the <a class="HZWKYxoXby-c81" href="https://github.com/maddiestone/ConPresentations/blob/master/FIRST2022.2022_0days_so_far.pdf">slides from the talk</a>. When 0-day exploits are detected in-the-wild, it’s the failure case for an attacker. It’s a gift for us security defenders to learn as much as we can and take actions to ensure that that vector can’t be used again. The goal is to force attackers to start from scratch each time we detect one of their exploits: they’re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. To do that effectively, we need correct and comprehensive fixes. This is not to minimize the challenges faced by security teams responsible for responding to vulnerability reports. As we said in our 2020 year in review report: Being able to correctly and comprehensively patch isn't just flicking a switch: it requires investment, prioritization, and planning. It also requires developing a patching process that balances both protecting users quickly and ensuring it is comprehensive, which can at times be in tension. While we expect that none of this will come as a surprise to security teams in an organization, this analysis is a good reminder that there is still more work to be done. Exactly what investments are likely required depends on each unique situation, but we see some common themes around staffing/resourcing, incentive structures, process maturity, automation/testing, release cadence, and partnerships.   Practically, some of the following efforts can help ensure bugs are correctly and comprehensively fixed. Project Zero plans to continue to help with the following efforts, but we hope and encourage platform security teams and other independent security researchers to invest in these types of analyses as well:<ul style="padding: 0;" class="c13 lst-kix_68660h7uawx-0 start"><li style="margin-left: 46pt;" class="c6 c18 li-bullet-0">Root cause analysis</li></ul> Understanding the underlying vulnerability that is being exploited. Also tries to understand how that vulnerability may have been introduced. Performing a root cause analysis can help ensure that a fix is addressing the underlying vulnerability and not just breaking the proof-of-concept. Root cause analysis is generally a pre-requisite for successful variant and patch analysis.<ul style="padding: 0;" class="c13 lst-kix_68660h7uawx-0"><li style="margin-left: 46pt;" class="c6 c18 li-bullet-0">Variant analysis</li></ul> Looking for other vulnerabilities similar to the reported vulnerability. This can involve looking for the same bug pattern elsewhere, more thoroughly auditing the component that contained the vulnerability, modifying fuzzers to understand why they didn’t find the vulnerability previously, etc. Most researchers find more than one vulnerability at the same time. By finding and fixing the related variants, attackers are not able to simply “plug and play” with a new vulnerability once the original is patched.<ul style="padding: 0;" class="c13 lst-kix_68660h7uawx-0"><li style="margin-left: 46pt;" class="c6 c18 li-bullet-0">Patch analysis</li></ul> Analyzing the proposed (or released) patch for completeness compared to the root cause vulnerability. I encourage vendors to share how they plan to address the vulnerability with the vulnerability reporter early so the reporter can analyze whether the patch comprehensively addresses the root cause of the vulnerability, alongside the vendor’s own internal analysis.<ul style="padding: 0;" class="c13 lst-kix_68660h7uawx-0"><li style="margin-left: 46pt;" class="c6 c18 li-bullet-0">Exploit technique analysis</li></ul> Understanding the primitive gained from the vulnerability and how it’s being used. While it’s generally industry-standard to patch vulnerabilities, mitigating exploit techniques doesn’t happen as frequently. While not every exploit technique will always be able to be mitigated, the hope is that it will become the default rather than the exception. Exploit samples will need to be shared more readily in order for vendors and security researchers to be able to perform exploit technique analysis. Transparently sharing these analyses helps the industry as a whole as well. We publish our analyses at <a class="HZWKYxoXby-c81" href="https://googleprojectzero.github.io/0days-in-the-wild/rca.html">this repository</a>. We encourage vendors and others to publish theirs as well. This allows developers and security professionals to better understand what the attackers already know about these bugs, which hopefully leads to even better solutions and security overall.   <div style='clear: both;'></div> </div> <div class='post-footer'> <div class='post-footer-line post-footer-line-1'> Posted by <meta content='https://www.blogger.com/profile/08975904405228580347' itemprop='url'/> <a class='g-profile' href='https://www.blogger.com/profile/08975904405228580347' rel='author' title='author profile'> Google Project Zero </a> at <meta content='https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html' itemprop='url'/> <a class='timestamp-link' href='https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html' rel='bookmark' title='permanent link'><abbr class='published' itemprop='datePublished' title='2022-06-30T06:00:00-07:00'>6:00 AM</abbr></a> <a class='comment-link' href='https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html#comment-form' onclick=''> No comments: </a> <a href='https://www.blogger.com/post-edit.g?blogID=4838136820032157985&postID=256978548158816980&from=pencil' title='Edit Post'> <img alt='' class='icon-action' height='18' src='https://resources.blogblog.com/img/icon18_edit_allbkg.gif' width='18'/> </a> <div class='post-share-buttons goog-inline-block'> <a class='goog-inline-block share-button sb-email' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=256978548158816980&target=email' target='_blank' title='Email This'>Email This</a><a class='goog-inline-block share-button sb-blog' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=256978548158816980&target=blog' onclick='window.open(this.href, "_blank", "height=270,width=475"); return false;' target='_blank' title='BlogThis!'>BlogThis!</a><a class='goog-inline-block share-button sb-twitter' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=256978548158816980&target=twitter' target='_blank' title='Share to X'>Share to X</a><a class='goog-inline-block share-button sb-facebook' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=256978548158816980&target=facebook' onclick='window.open(this.href, "_blank", "height=430,width=640"); return false;' target='_blank' title='Share to Facebook'>Share to Facebook</a><a class='goog-inline-block share-button sb-pinterest' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=256978548158816980&target=pinterest' target='_blank' title='Share to Pinterest'>Share to Pinterest</a> </div> </div> <div class='post-footer-line post-footer-line-2'> </div> <div class='post-footer-line post-footer-line-3'> </div> </div> </div> </div> </div></div> <div class="date-outer"> <h2 class='date-header'>Thursday, June 23, 2022</h2> <div class="date-posts"> <div class='post-outer'> <div class='post hentry uncustomized-post-template' itemprop='blogPost' itemscope='itemscope' itemtype='http://schema.org/BlogPosting'> <meta content='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioBjlvs-GjJW9ZocxERk7cU6J-bBcWIjauCAzuI6QoMvdQENbSjF6elAZ0yUpLbHfTmOzfdKWBhB_FFR8X9UF1yMqN9XSMmJSUDZ_uVX_zctpmYMaD0G6V7bi68tdJ2C-e3eyM715_cTywzOWAgSbPyazbNtMv65p0lWewhacxCox_vrztKXdRZdjB/s1200/Screenshot%202022-06-22%20at%2016.52.33.png' itemprop='image_url'/> <meta content='4838136820032157985' itemprop='blogId'/> <meta content='5973748726134682294' itemprop='postId'/> <a name='5973748726134682294'></a> <h3 class='post-title entry-title' itemprop='name'> <a href='https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html'>The curious tale of a fake Carrier.app</a> </h3> <div class='post-header'> <div class='post-header-line-1'></div> </div> <div class='post-body entry-content' id='post-body-5973748726134682294' itemprop='description articleBody'> <style type="text/css">@import url('https://themes.googleusercontent.com/fonts/css?kit=cGvuclDC_Z1vE_cnVEU6Ae_NZQ7StBcqH_vXVqoPMX0');ol{margin:0;padding:0}table td,table th{padding:0}.HovzfPYjjR-c13{border-right-style:solid;padding:5pt 5pt 5pt 5pt;border-bottom-color:#e0e0e0;border-top-width:1pt;border-right-width:1pt;border-left-color:#e0e0e0;vertical-align:top;border-right-color:#e0e0e0;border-left-width:1pt;border-top-style:solid;background-color:#fafafa;border-left-style:solid;border-bottom-width:1pt;width:468pt;border-top-color:#e0e0e0;border-bottom-style:solid}.HovzfPYjjR-c34{padding-top:0pt;padding-bottom:3pt;line-height:1.5;page-break-after:avoid;text-align:left}.HovzfPYjjR-c15{padding-top:18pt;padding-bottom:6pt;line-height:1.5;page-break-after:avoid;text-align:left}.HovzfPYjjR-c17{text-decoration-skip-ink:none;-webkit-text-decoration-skip:none;color:#1155cc;text-decoration:underline}.HovzfPYjjR-c31{padding-top:0pt;padding-bottom:0pt;line-height:1.5;text-align:center}.HovzfPYjjR-c6{color:#000000;font-weight:400;font-size:11pt;font-family:"Courier New"}.HovzfPYjjR-c9{font-size:10pt;font-family:Consolas,"Courier New";color:#9c27b0;font-weight:400}.HovzfPYjjR-c0{font-size:10pt;font-family:Consolas,"Courier New";color:#000000;font-weight:400}.HovzfPYjjR-c30{font-size:10pt;font-family:Consolas,"Courier New";color:#455a64;font-weight:400}.HovzfPYjjR-c20{border-spacing:0;border-collapse:collapse;margin-right:auto}.HovzfPYjjR-c3{padding-top:0pt;padding-bottom:0pt;line-height:1.5;text-align:left}.HovzfPYjjR-c14{font-size:10pt;font-family:Consolas,"Courier New";color:#3367d6;font-weight:400}.HovzfPYjjR-c16{color:#000000;font-weight:400;font-size:16pt;font-family:"Arial"}.HovzfPYjjR-c5{color:#000000;font-weight:400;font-size:11pt;font-family:"Arial"}.HovzfPYjjR-c27{color:#000000;font-weight:700;font-size:11pt;font-family:"Arial"}.HovzfPYjjR-c23{font-size:10pt;font-family:Consolas,"Courier New";color:#c53929;font-weight:700}.HovzfPYjjR-c22{font-size:10pt;font-family:Consolas,"Courier New";color:#0f9d58;font-weight:400}.HovzfPYjjR-c1{font-size:10pt;font-family:Consolas,"Courier New";color:#616161;font-weight:400}.HovzfPYjjR-c4{font-size:10pt;font-family:Consolas,"Courier New";color:#c53929;font-weight:400}.HovzfPYjjR-c24{padding-top:0pt;padding-bottom:0pt;line-height:1.5;text-align:right}.HovzfPYjjR-c21{color:#000000;font-weight:400;font-size:26pt;font-family:"Arial"}.HovzfPYjjR-c2{text-decoration:none;vertical-align:baseline;font-style:normal}.HovzfPYjjR-c33{background-color:#ffffff;max-width:468pt;padding:72pt 72pt 72pt 72pt}.HovzfPYjjR-c32{margin-left:22.5pt;text-indent:36pt}.HovzfPYjjR-c19{color:inherit;text-decoration:inherit}.HovzfPYjjR-c26{font-weight:700;font-family:"Courier New"}.HovzfPYjjR-c7{font-weight:400;font-family:"Courier New"}.HovzfPYjjR-c28{text-decoration:none;vertical-align:baseline}.HovzfPYjjR-c8{orphans:2;widows:2}.HovzfPYjjR-c29{font-weight:700}.HovzfPYjjR-c18{height:0pt}.HovzfPYjjR-c25{font-style:italic}.HovzfPYjjR-c11{background-color:#00ff00}.HovzfPYjjR-c12{margin-right:-45pt}.HovzfPYjjR-c10{height:11pt}.title{padding-top:0pt;color:#000000;font-size:26pt;padding-bottom:3pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}.subtitle{padding-top:0pt;color:#666666;font-size:15pt;padding-bottom:16pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}li{color:#000000;font-size:11pt;font-family:"Arial"}p{margin:0;color:#000000;font-size:11pt;font-family:"Arial"}h1{padding-top:20pt;color:#000000;font-size:20pt;padding-bottom:6pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h2{padding-top:18pt;color:#000000;font-size:16pt;padding-bottom:6pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h3{padding-top:16pt;color:#434343;font-size:14pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h4{padding-top:14pt;color:#666666;font-size:12pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h5{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;orphans:2;widows:2;text-align:left}h6{padding-top:12pt;color:#666666;font-size:11pt;padding-bottom:4pt;font-family:"Arial";line-height:1.5;page-break-after:avoid;font-style:italic;orphans:2;widows:2;text-align:left}</style><body class="HovzfPYjjR-c33"> Posted by Ian Beer, Google Project Zero NOTE: This issue was CVE-2021-30983 was fixed in iOS 15.2 in December 2021.  Towards the end of 2021 Google's Threat Analysis Group (TAG) shared an iPhone app with me: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioBjlvs-GjJW9ZocxERk7cU6J-bBcWIjauCAzuI6QoMvdQENbSjF6elAZ0yUpLbHfTmOzfdKWBhB_FFR8X9UF1yMqN9XSMmJSUDZ_uVX_zctpmYMaD0G6V7bi68tdJ2C-e3eyM715_cTywzOWAgSbPyazbNtMv65p0lWewhacxCox_vrztKXdRZdjB/s1874/Screenshot%202022-06-22%20at%2016.52.33.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="App splash screen showing the Vodafone carrier logo and the text My Vodafone." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioBjlvs-GjJW9ZocxERk7cU6J-bBcWIjauCAzuI6QoMvdQENbSjF6elAZ0yUpLbHfTmOzfdKWBhB_FFR8X9UF1yMqN9XSMmJSUDZ_uVX_zctpmYMaD0G6V7bi68tdJ2C-e3eyM715_cTywzOWAgSbPyazbNtMv65p0lWewhacxCox_vrztKXdRZdjB/s1200/Screenshot%202022-06-22%20at%2016.52.33.png" style="max-height: 750px; max-width: 600px;" title="App splash screen showing the Vodafone carrier logo and the text My Vodafone." /></a><img /> App splash screen showing the Vodafone carrier logo and the text "My Vodafone" (not the legitimate Vodadone app) Although this looks like the real <a class="HovzfPYjjR-c191" href="https://apps.apple.com/gb/app/my-vodafone/id370901726">My Vodafone carrier app</a> available in the App Store, it didn't come from the App Store and is not the real application from Vodafone. TAG suspects that a target receives a link to this app in an SMS, after the attacker asks the carrier to disable the target's mobile data connection. The SMS claims that in order to restore mobile data connectivity, the target must install the carrier app and includes a link to download and install this fake app. This sideloading works because the app is signed with an enterprise certificate, which can be purchased for $299 via the Apple <a class="HovzfPYjjR-c191" href="https://developer.apple.com/programs/enterprise/">Enterprise developer program</a>. This program allows an eligible enterprise to obtain an Apple-signed embedded.mobileprovision file with the ProvisionsAllDevices key set. An app signed with the developer certificate embedded within that mobileprovision file can be sideloaded on any iPhone, bypassing Apple's App Store review process. While we understand that the Enterprise developer program is designed for companies to push "trusted apps" to their staff's iOS devices, in this case, it appears that it was being used to sideload this fake carrier app. In collaboration with Project Zero, <a href="https://blog.google/threat-analysis-group/italian-spyware-vendor-targets-users-in-italy-and-kazakhstan/" target="_blank">TAG has published an additional post with more details around the targeting and the actor</a>. The rest of this blogpost is dedicated to the technical analysis of the app and the exploits contained therein.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.rengd0ayidhp">App structure</h2> The app is broken up into multiple frameworks. InjectionKit.framework is a generic privilege escalation exploit wrapper, exposing the primitives you'd expect (kernel memory access, entitlement injection, amfid bypasses) as well as higher-level operations like app installation, file creation and so on. Agent.framework is partially obfuscated but, as the name suggests, seems to be a basic agent able to find and exfiltrate interesting files from the device like the Whatsapp messages database. Six privilege escalation exploits are bundled with this app. Five are well-known, publicly available N-day exploits for older iOS versions. The sixth is not like those others at all. This blog post is the story of the last exploit and the month-long journey to understand it.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.nr1ejtuvx4nm">Something's missing? Or am I missing something?</h2> Although all the exploits were different, five of them shared a common high-level structure. An initial phase where the kernel heap was manipulated to control object placement. Then the triggering of a kernel vulnerability followed by well-known steps to turn that into something useful, perhaps by disclosing kernel memory then building an arbitrary kernel memory write primitive. The sixth exploit didn't have anything like that. Perhaps it could be triggering a kernel logic bug like Linuz Henze's <a class="HovzfPYjjR-c191" href="https://github.com/LinusHenze/Fugu14">Fugu14</a> exploit, or a very bad memory safety issue which gave fairly direct kernel memory access. But neither of those seemed very plausible either. It looked, quite simply, like an iOS kernel exploit from a decade ago, except one which was first quite carefully checking that it was only running on an iPhone 12 or 13. It contained log messages like:   printf("Failed to prepare fake vtable: 0x%08x", ret); which seemed to happen far earlier than the exploit could possibly have defeated mitigations like KASLR and PAC. Shortly after that was this log message:   printf("Waiting for R/W primitives..."); Why would you need to wait? Then shortly after that:   printf("Memory read/write and callfunc primitives ready!"); Up to that point the exploit made only four IOConnectCallMethod calls and there were no other obvious attempts at heap manipulation. But there was another log message which started to shed some light:   printf("Unexpected data read from DCP: 0x%08x", v49);<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.dlybqvef2fq5">DCP?</h2> In October 2021 Adam Donenfeld tweeted this: <img /> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgizH1ivW5VjBBB2oIDHbvRvevtn3SaYgaWlwf_F_bWSAb9b9kMrycHwATVj_tyHb22sjTc9jJmwQTc-ehvzmruznZtyWToUNiEfyif6nl3latUr3STT8P0YSL0MgxB8_t-CjNLdHITK0kpCcuYPJhFN7zuOX6s1DqOQVQxthrazNfK0ktsvn4Na1hl/s1988/Screenshot%202022-06-22%20at%2016.52.56.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="Screenshot of Tweet from @doadam on 11 Oct 2021, which is a retweet from @AmarSaar on 11 October 2021. The tweet from @AmarSaar reads 'So, another IOMFB vulnerability was exploited ITW (15.0.2). I bindiffed the patch and built a POC. And, because it's a great bug, I just finished writing a short blogpost with the tech details, to share this knowledge :) Check it out! https://saaramar.github.io/IOMFB_integer_overflow_poc/' and the retweet from @doadam reads 'This has been moved to the display coprocessor (DCP) starting from 15, at least on iPhone 12 (and most probably other ones as well)'." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgizH1ivW5VjBBB2oIDHbvRvevtn3SaYgaWlwf_F_bWSAb9b9kMrycHwATVj_tyHb22sjTc9jJmwQTc-ehvzmruznZtyWToUNiEfyif6nl3latUr3STT8P0YSL0MgxB8_t-CjNLdHITK0kpCcuYPJhFN7zuOX6s1DqOQVQxthrazNfK0ktsvn4Na1hl/s1200/Screenshot%202022-06-22%20at%2016.52.56.png" style="max-height: 750; max-width: 600px;" title="Screenshot of Tweet from @doadam on 11 Oct 2021, which is a retweet from @AmarSaar on 11 October 2021. The tweet from @AmarSaar reads 'So, another IOMFB vulnerability was exploited ITW (15.0.2). I bindiffed the patch and built a POC. And, because it's a great bug, I just finished writing a short blogpost with the tech details, to share this knowledge :) Check it out! https://saaramar.github.io/IOMFB_integer_overflow_poc/' and the retweet from @doadam reads 'This has been moved to the display coprocessor (DCP) starting from 15, at least on iPhone 12 (and most probably other ones as well)'." /></a> DCP is the "Display Co-Processor" which ships with iPhone 12 and above and all M1 Macs. There's little public information about the DCP; the most comprehensive comes from the <a class="HovzfPYjjR-c191" href="https://asahilinux.org/">Asahi linux project</a> which is porting linux to M1 Macs. In their <a class="HovzfPYjjR-c191" href="https://asahilinux.org/2021/08/progress-report-august-2021/">August 2021</a> and <a class="HovzfPYjjR-c191" href="https://asahilinux.org/2021/10/progress-report-september-2021/">September 2021</a> updates they discussed their DCP reverse-engineering efforts and the open-source DCP client written by <a class="HovzfPYjjR-c191" href="https://twitter.com/alyssarzg">@alyssarzg</a>. Asahi describe the DCP like this: On most mobile SoCs, the display controller is just a piece of hardware with simple registers. While this is true on the M1 as well, Apple decided to give it a twist. They added a coprocessor to the display engine (called DCP), which runs its own firmware (initialized by the system bootloader), and moved most of the display driver into the coprocessor. But instead of doing it at a natural driver boundary… they took half of their macOS C++ driver, moved it into the DCP, and created a remote procedure call interface so that each half can call methods on C++ objects on the other CPU! <a class="HovzfPYjjR-c191" href="https://asahilinux.org/2021/08/progress-report-august-2021/">https://asahilinux.org/2021/08/progress-report-august-2021/</a> The Asahi linux project reverse-engineered the API to talk to the DCP but they are restricted to using Apple's DCP firmware (loaded by iBoot) - they can't use a custom DCP firmware. Consequently their documentation is limited to the DCP RPC API with few details of the DCP internals.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.nj6hztnr911v">Setting the stage</h2> Before diving into DCP internals it's worth stepping back a little. What even is a co-processor in a modern, highly integrated SoC (System-on-a-Chip) and what might the consequences of compromising it be? Years ago a co-processor would likely have been a physically separate chip. Nowadays a large number of these co-processors are integrated along with their interconnects directly onto a single die, even if they remain fairly independent systems. We can see in this M1 die shot from <a class="HovzfPYjjR-c191" href="https://www.techinsights.com/blog/two-new-apple-socs-two-market-events-apple-a14-and-m1">Tech Insights</a> that the CPU cores in the middle and right hand side take up only around 10% of the die: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjtJjSN0qdOa1cKBG72s9uuwcVKU5evSg9CiIPtpbbFox0fGgW7XZQU1Jj4IezjIdHC23sJbnklT6acyTFiqB-0-qmcj35Gq-ZZyTHP0DcfFkBztA0DL2P3lhYy2n0k8wgzmzaYX8IMeKosr4uuWMXT-wplsuJQmfR4LDgFzWAUZARvx5rfWjWiusz/s1116/Screenshot%202022-06-22%20at%2016.53.12.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="M1 die-shot from techinsights.com with possible location of DCP highlighted." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjtJjSN0qdOa1cKBG72s9uuwcVKU5evSg9CiIPtpbbFox0fGgW7XZQU1Jj4IezjIdHC23sJbnklT6acyTFiqB-0-qmcj35Gq-ZZyTHP0DcfFkBztA0DL2P3lhYy2n0k8wgzmzaYX8IMeKosr4uuWMXT-wplsuJQmfR4LDgFzWAUZARvx5rfWjWiusz/s1116/Screenshot%202022-06-22%20at%2016.53.12.png" style="max-height: 750; max-width: 600px;" title="M1 die-shot from techinsights.com with possible location of DCP highlighted." /></a> M1 die-shot from techinsights.com with possible location of DCP added <a class="HovzfPYjjR-c191" href="https://www.techinsights.com/blog/two-new-apple-socs-two-market-events-apple-a14-and-m1">https://www.techinsights.com/blog/two-new-apple-socs-two-market-events-apple-a14-and-m1</a> Companies like <a class="HovzfPYjjR-c191" href="https://www.systemplus.fr/">SystemPlus</a> perform <a class="HovzfPYjjR-c191" href="https://www.systemplus.fr/wp-content/uploads/2020/12/SP20608-Apple-M1-System-on-Chip-Sample.pdf">very thorough analysis of these dies</a>. Based on their analysis the DCP is likely the rectangular region indicated on this M1 die. It takes up around the same amount of space as the four high-efficiency cores seen in the centre, though it seems to be mostly SRAM. With just this low-resolution image it's not really possible to say much more about the functionality or capabilities of the DCP and what level of system access it has. To answer those questions we'll need to take a look at the firmware.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.mnw2kq5jkaze">My kingdom for a .dSYM!</h2> The first step is to get the DCP firmware image. iPhones (and now M1 macs) use .ipsw files for system images. An .ipsw is really just a .zip archive and the Firmware/ folder in the extracted .zip contains all the firmware for the co-processors, modems etc. The DCP firmware is this file:<hr style="display: none; page-break-before: always;" />   Firmware/dcp/iphone13dcp.im4p The im4p in this case is just a 25 byte header which we can discard:   $ dd if=iphone13dcp.im4p of=iphone13dcp bs=25 skip=1   $ file iphone13dcp   iphone13dcp: Mach-O 64-bit preload executable arm64 It's a Mach-O! Running nm -a to list all symbols shows that the binary has been fully stripped:   $ nm -a iphone13dcp   iphone13dcp: no symbols Function names make understanding code significantly easier. From looking at the handful of strings in the exploit some of them looked like they might be referencing symbols in a DCP firmware image ("M3_CA_ResponseLUT read: 0x%08x" for example) so I thought perhaps there might be a DCP firmware image where the symbols hadn't been stripped. Since the firmware images are distributed as .zip files and Apple's servers support range requests with a bit of python and the <a class="HovzfPYjjR-c191" href="https://github.com/marcograss/partialzip">partialzip</a> tool we can relatively easily and quickly get every beta and release DCP firmware. I checked over 300 distinct images; every single one was stripped. Guess we'll have to do this the hard way!<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.m9onjpj2j9i">Day 1; Instruction 1</h2> $ otool -h raw_fw/iphone13dcp raw_fw/iphone13dcp: Mach header magic      cputype   cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 0x100000C 0          0x00 5        5     2240       0x00000001 That cputype is plain arm64 (ArmV8) without pointer authentication support. The binary is fairly large (3.7MB) and IDA's autoanalysis detects over 7000 functions. With any brand new binary I usually start with a brief look through the function names and the strings. The binary is stripped so there are no function name symbols but there are plenty of C++ function names as strings: <img /> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY8rBSaTDR2W5pSgk9ssaCqN8M8Nuhd5_x6FkNSqOI-jRDFVab_jrrkZlN1DS2FKf9zeAPPDFkE30kNCPpN3PES9RdvBLj4L6G78zq134bTQcR1VEe7J30tYPoqqZ82z1cPwUcvF2wzfoOEbDf3l_4ucxpuOZFC2NLyrMYV_luJ_5dysxanajqsi-N/s1830/Screenshot%202022-06-22%20at%2016.53.26.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="A short list of C++ prototypes like IOMFB::UPBlock_ALSS::init(IOMFB::UPPipe *)." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY8rBSaTDR2W5pSgk9ssaCqN8M8Nuhd5_x6FkNSqOI-jRDFVab_jrrkZlN1DS2FKf9zeAPPDFkE30kNCPpN3PES9RdvBLj4L6G78zq134bTQcR1VEe7J30tYPoqqZ82z1cPwUcvF2wzfoOEbDf3l_4ucxpuOZFC2NLyrMYV_luJ_5dysxanajqsi-N/s1200/Screenshot%202022-06-22%20at%2016.53.26.png" style="max-height: 750; max-width: 600px;" title="A short list of C++ prototypes like IOMFB::UPBlock_ALSS::init(IOMFB::UPPipe *)." /></a> The cross-references to those strings look like this: <a id="t.c7f36f1411586a1b165d5a48e181a07b7b9d07a6"></a><a id="t.0"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> log(0x40000001LL,     "UPBlock_ALSS.cpp",     341,     "%s: capture buffer exhausted, aborting capture\n",     "void IOMFB::UPBlock_ALSS::send_data(uint64_t, uint32_t)");</td></tr></table> This is almost certainly a logging macro which expands __FILE__, __LINE__ and __PRETTY_FUNCTION__. This allows us to start renaming functions and finding vtable pointers.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.72tz1dtagcu2">Object structure</h2> From the Asahi linux blog posts we know that the DCP is using an Apple-proprietary RTOS called RTKit for which there is very little public information. There are some strings in the binary with the exact version: ADD  X8, X8, #aLocalIphone13d@PAGEOFF ; "local-iphone13dcp.release" ADD  X9, X9, #aRtkitIos182640@PAGEOFF ; "RTKit_iOS-1826.40.9.debug" The code appears to be predominantly C++. There appear to be multiple C++ object hierarchies; those involved with this vulnerability look a bit like IOKit C++ objects. Their common base class looks like this: <a id="t.23741390b29a0e8a199a26eb39699e3e43f7695e"></a><a id="t.1"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct __cppobj RTKIT_RC_RTTI_BASE {   RTKIT_RC_RTTI_BASE_vtbl *__vftable /*VFT*/;   uint32_t refcnt;   uint32_t typeid; };</td></tr></table> (These structure definitions are in the format IDA uses for C++-like objects) The RTKit base class has a vtable pointer, a reference count and a four-byte Run Time Type Information (RTTI) field - a 4-byte ASCII identifier like BLHA, WOLO, MMAP, UNPI, OSST, OSBO and so on. These identifiers look a bit cryptic but they're quite descriptive once you figure them out (and I'll describe the relevant ones as we encounter them.) The base type has the following associated vtable: <a id="t.e2f588f986d4c4d814dde7976c00d512e7353bbe"></a><a id="t.2"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct /*VFT*/ RTKIT_RC_RTTI_BASE_vtbl {   void (__cdecl *take_ref)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *drop_ref)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *take_global_type_ref)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *drop_global_type_ref)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *getClassName)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *dtor_a)(RTKIT_RC_RTTI_BASE *this);   void (__cdecl *unk)(RTKIT_RC_RTTI_BASE *this); };</td></tr></table><h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.17hwrgmah5ee">Exploit flow</h2> The exploit running in the app starts by opening an IOKit user client for the AppleCLCD2 service. AppleCLCD seems to be the application processor of IOMobileFrameBuffer and AppleCLCD2 the DCP version. The exploit only calls 3 different external method selectors on the AppleCLCD2 user client: 68, 78 and 79. The one with the largest and most interesting-looking input is 78, which corresponds to this user client method in the kernel driver: <a id="t.c1d0de88bea2ae99b6a4f974f60cac134013db41"></a><a id="t.3"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> IOReturn IOMobileFramebufferUserClient::s_set_block(   IOMobileFramebufferUserClient *this,   void *reference,   IOExternalMethodArguments *args) {   const unsigned __int64 *extra_args;   u8 *structureInput;   structureInput = args->structureInput;   if ( structureInput && args->scalarInputCount >= 2 )   {     if ( args->scalarInputCount == 2 )       extra_args = 0LL;     else       extra_args = args->scalarInput + 2;     return this->framebuffer_ap->set_block_dcp(              this->task,              args->scalarInput[0],              args->scalarInput[1],              extra_args,              args->scalarInputCount - 2,              structureInput,              args->structureInputSize);   } else {     return 0xE00002C2;   } }</td></tr></table> this unpacks the IOConnectCallMethod arguments and passes them to: <a id="t.4b4f98b94b8ed8638b5222e4f9d81049bbe69fdb"></a><a id="t.4"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> IOMobileFramebufferAP::set_block_dcp(         IOMobileFramebufferAP *this,         task *task,         int first_scalar_input,         int second_scalar_input,         const unsigned __int64 *pointer_to_remaining_scalar_inputs,         unsigned int scalar_input_count_minus_2,         const unsigned __int8 *struct_input,         unsigned __int64 struct_input_size)</td></tr></table> This method uses some autogenerated code to serialise the external method arguments into a buffer like this: <a id="t.26b4f1ef327e79bf7a370b395d86bddb90eb464f"></a><a id="t.5"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> arg_struct: {   struct task* task   u64 scalar_input_0   u64 scalar_input_1   u64[] remaining_scalar_inputs   u64 cntExtraScalars   u8[] structInput   u64 CntStructInput }</td></tr></table> which is then passed to UnifiedPipeline2::rpc along with a 4-byte ASCII method identifier ('A435' here): <a id="t.afc7096b3986ce85a82073984786eb19b4fcdb59"></a><a id="t.6"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> UnifiedPipeline2::rpc(       'A435',       arg_struct,       0x105Cu,       &retval_buf,       4u);</td></tr></table> UnifiedPipeline2::rpc calls DCPLink::rpc which calls AppleDCPLinkService::rpc to perform one more level of serialisation which packs the method identifier and a "stream identifier" together with the arg_struct shown above. AppleDCPLinkService::rpc then calls rpc_caller_gated to allocate space in a shared memory buffer, copy the buffer into there then signal to the DCP that a message is available. Effectively the implementation of the IOMobileFramebuffer user client has been moved on to the DCP and the external method interface is now a proxy shim, via shared memory, to the actual implementations of the external methods which run on the DCP.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.5nfahlo9nbh6">Exploit flow: the other side</h2> The next challenge is to find where the messages start being processed on the DCP. Looking through the log strings there's a function which is clearly called rpc_callee_gated - quite likely that's the receive side of the function rpc_caller_gated we saw earlier. rpc_callee_gated unpacks the wire format then has an enormous switch statement which maps all the 4-letter RPC codes to function pointers: <a id="t.47d68344bf5cd802c2cfc796e38eefd94678d525"></a><a id="t.7"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1">       switch ( rpc_id )       {         case 'A000':           goto LABEL_146;         case 'A001':           handler_fptr = callback_handler_A001;           break;         case 'A002':           handler_fptr = callback_handler_A002;           break;         case 'A003':           handler_fptr = callback_handler_A003;           break;         case 'A004':           handler_fptr = callback_handler_A004;           break;         case 'A005':           handler_fptr = callback_handler_A005;           break;</td></tr></table> At the the bottom of this switch statement is the invocation of the callback handler: <a id="t.727f8d6109f87f45ecfc47e4cbc67fff73f299cf"></a><a id="t.8"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> ret = handler_fptr(           meta,           in_struct_ptr,           in_struct_size,           out_struct_ptr,           out_struct_size);</td></tr></table> in_struct_ptr points to a copy of the serialised IOConnectCallMethod arguments we saw being serialized earlier on the application processor: <a id="t.a1bc79b6e0e53aa6513e954a3be969c86fa9de29"></a><a id="t.9"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> arg_struct: {   struct task* task   u64 scalar_input_0   u64 scalar_input_1   u64[] remaining_scalar_inputs   u32 cntExtraScalars   u8[] structInput   u64 cntStructInput }</td></tr></table> The callback unpacks that buffer and calls a C++ virtual function: <a id="t.423c597cfa08d39f62002779d1150a8e593d7557"></a><a id="t.10"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> unsigned int callback_handler_A435(   u8* meta,   void *args,   uint32_t args_size,   void *out_struct_ptr,   uint32_t out_struct_size {   int64 instance_id;   uint64_t instance;   int err;   int retval;   unsigned int result;   instance_id = meta->instance_id;   instance =     global_instance_table[instance_id].IOMobileFramebufferType;   if ( !instance ) {     log_fatal(       "IOMFB: %s: no instance for instance ID: %u\n",       "static T *IOMFB::InstanceTracker::instance"         "(IOMFB::InstanceTracker::tracked_entity_t, uint32_t)"         " [T = IOMobileFramebuffer]",       instance_id);   }   err = (instance-16)->vtable_0x378( // virtual call          (instance-16),          args->task,          args->scalar_input_0,          args->scalar_input_1,          args->remaining_scalar_inputs,          args->cntExtraScalars,          args->structInput,          args->cntStructInput);   retval = convert_error(err);   result = 0;   *(_DWORD *)out_struct_ptr = retval;   return result; }</td></tr></table> The challenge here is to figure out where that virtual call goes. The object is being looked up in a global table based on the instance id. We can't just set a breakpoint and whilst emulating the firmware is probably possible that would likely be a long project in itself. I took a hackier approach: we know that the vtable needs to be at least 0x380 bytes large so just go through all those vtables, decompile them and see if the prototypes look reasonable! There's one clear match in the vtable for the UNPI type: <a id="t.ac38f56155b7d2697b0aee9ae6858f6b42815b34"></a><a id="t.11"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> UNPI::set_block(         UNPI* this,         struct task* caller_task_ptr,         unsigned int first_scalar_input,         int second_scalar_input,         int *remaining_scalar_inputs,         uint32_t cnt_remaining_scalar_inputs,         uint8_t *structure_input_buffer,         uint64_t structure_input_size)</td></tr></table> Here's my reversed implementation of UNPI::set_block <a id="t.3aba48cdaac58ae867b60889bc2f2ff94e4953a6"></a><a id="t.12"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> UNPI::set_block(         UNPI* this,         struct task* caller_task_ptr,         unsigned int first_scalar_input,         int second_scalar_input,         int *remaining_scalar_inputs,         uint32_t cnt_remaining_scalar_inputs,         uint8_t *structure_input_buffer,         uint64_t structure_input_size) {   struct block_handler_holder *holder;   struct metadispatcher metadisp;   if ( second_scalar_input )     return 0x80000001LL;   holder = this->UPPipeDCP_H13P->block_handler_holders;   if ( !holder )     return 0x8000000BLL;   metadisp.address_of_some_zerofill_static_buffer = &unk_3B8D18;   metadisp.handlers_holder = holder;   metadisp.structure_input_buffer = structure_input_buffer;   metadisp.structure_input_size = structure_input_size;   metadisp.remaining_scalar_inputs = remaining_scalar_inputs;   metadisp.cnt_remaining_sclar_input = cnt_remaining_scalar_inputs;   metadisp.some_flags = 0x40000000LL;   metadisp.dispatcher_fptr = a_dispatcher;   metadisp.offset_of_something_which_looks_serialization_related = &off_1C1308;   return metadispatch(holder, first_scalar_input, 1, caller_task_ptr, structure_input_buffer, &metadisp, 0); }</td></tr></table> This method wraps up the arguments into another structure I've called metadispatcher: <a id="t.70518115c511a294cd855553b9003a0771a08ccd"></a><a id="t.13"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct __attribute__((aligned(8))) metadispatcher {  uint64_t address_of_some_zerofill_static_buffer;  uint64_t some_flags;  __int64 (__fastcall *dispatcher_fptr)(struct metadispatcher *, struct BlockHandler *, __int64, _QWORD);  uint64_t offset_of_something_which_looks_serialization_related;  struct block_handler_holder *handlers_holder;  uint64_t structure_input_buffer;  uint64_t structure_input_size;  uint64_t remaining_scalar_inputs;  uint32_t cnt_remaining_sclar_input; };</td></tr></table> That metadispatcher object is then passed to this method: <a id="t.9e3136a3d4346cb21c1c8dc0948c6e7439c8fc5f"></a><a id="t.14"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> return metadispatch(holder, first_scalar_input, 1, caller_task_ptr, structure_input_buffer, &metadisp, 0);</td></tr></table> In there we reach this code: <a id="t.b1eaf3e2e954d8f37bc987b98c30e92ce161e849"></a><a id="t.15"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1">   block_type_handler = lookup_a_handler_for_block_type_and_subtype(                          a1,                          first_scalar_input, // block_type                          a3);                // subtype</td></tr></table> The exploit calls this set_block external method twice, passing two different values for first_scalar_input, 7 and 19. Here we can see that those correspond to looking up two different block handler objects here. The lookup function searches a linked list of block handler structures; the head of the list is stored at offset 0x1448 in the UPPipeDCP_H13P object and registered dynamically by a method I've named add_handler_for_block_type: <a id="t.0dbaa54d4462638b9beda378f3267a7a7c4ded25"></a><a id="t.16"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> add_handler_for_block_type(struct block_handler_holder *handler_list,                            struct BlockHandler *handler)</td></tr></table> The logging code tells us that this is in a file called IOMFBBlockManager.cpp. IDA finds 44 cross-references to this method, indicating that there are probably that many different block handlers. The structure of each registered block handler is something like this: <a id="t.3c5d4c46eb785d82b4debfb43373bde140bc52fe"></a><a id="t.17"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct __cppobj BlockHandler : RTKIT_RC_RTTI_BASE {   uint64_t field_16;   struct handler_inner_types_entry *inner_types_array;   uint32_t n_inner_types_array_entries;   uint32_t field_36;   uint8_t can_run_without_commandgate;   uint32_t block_type;   uint64_t list_link;   uint64_t list_other_link;   uint32_t some_other_type_field;   uint32_t some_other_type_field2;   uint32_t expected_structure_io_size;   uint32_t field_76;   uint64_t getBlock_Impl;   uint64_t setBlock_Impl;   uint64_t field_96;   uint64_t back_ptr_to_UPPipeDCP_H13P; };</td></tr></table> The RTTI type is BLHA (BLock HAndler.) For example, here's the codepath which builds and registers block handler type 24: <a id="t.15a6e240c53ab46ec843eed2902a63a7ce3a078d"></a><a id="t.18"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> BLHA_24 = (struct BlockHandler *)CXXnew(112LL); BLHA_24->__vftable = (BlockHandler_vtbl *)BLHA_super_vtable; BLHA_24->block_type = 24; BLHA_24->refcnt = 1; BLHA_24->can_run_without_commandgate = 0; BLHA_24->some_other_type_field = 0LL; BLHA_24->expected_structure_io_size = 0xD20; typeid = typeid_BLHA(); BLHA_24->typeid = typeid; modify_typeid_ref(typeid, 1); BLHA_24->__vftable = vtable_BLHA_subclass_type_24; BLHA_24->inner_types_array = 0LL; BLHA_24->n_inner_types_array_entries = 0; BLHA_24->getBlock_Impl = BLHA_24_getBlock_Impl; BLHA_24->setBlock_Impl = BLHA_24_setBlock_Impl; BLHA_24->field_96 = 0LL; BLHA_24->back_ptr_to_UPPipeDCP_H13P = a1; add_handler_for_block_type(list_holder, BLHA_24);</td></tr></table> Each block handler optionally has getBlock_Impl and setBlock_Impl function pointers which appear to implement the actual setting and getting operations. We can go through all the callsites which add block handlers; tell IDA the type of the arguments and name all the getBlock and setBlock implementations: <img /> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-Z34Qgm9fUE2rzMwJWQ3j-w7InvtfHj5fs2qctSh0tTFmMbUpnrsQC4rUrhMf3_83uHAFinlM6xKqKXgUc2QR5IfL0gf4YEBM9Rqgrc6sNYsaCZ-JAe0PHlGa9VYcBgWfTqj5rTtin1mWTDG-I8K5M41EhA64KLNV54Sv9lvtbYIrkY2j37X6SniB/s1436/Screenshot%202022-06-22%20at%2016.53.47.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="The IDA Pro Names window showing a list of symbols like BLHA_15_getBlock_Impl." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-Z34Qgm9fUE2rzMwJWQ3j-w7InvtfHj5fs2qctSh0tTFmMbUpnrsQC4rUrhMf3_83uHAFinlM6xKqKXgUc2QR5IfL0gf4YEBM9Rqgrc6sNYsaCZ-JAe0PHlGa9VYcBgWfTqj5rTtin1mWTDG-I8K5M41EhA64KLNV54Sv9lvtbYIrkY2j37X6SniB/s1200/Screenshot%202022-06-22%20at%2016.53.47.png" style="max-height: 750; max-width: 600px;" title="The IDA Pro Names window showing a list of symbols like BLHA_15_getBlock_Impl." /></a> You can perhaps see where this is going: that's looking like really quite a lot of reachable attack surface! Each of those setBlock_Impl functions is reachable by passing a different value for the first scalar argument to IOConnectCallMethod 78. There's a little bit more reversing though to figure out how exactly to get controlled bytes to those setBlock_Impl functions:<h2 class="HovzfPYjjR-c8 HovzfPYjjR-c15" id="h.7aa6aljwlb56">Memory Mapping</h2> The raw "block" input to each of those setBlock_Impl methods isn't passed inline in the IOConnectCallMethod structure input. There's another level of indirection: each individual block handler structure has an array of supported "subtypes" which contains metadata detailing where to find the (userspace) pointer to that subtype's input data in the IOConnectCallMethod structure input. The first dword in the structure input is the id of this subtype - in this case for the block handler type 19 the metadata array has a single entry: <2, 0, 0x5F8, 0x600> The first value (2) is the subtype id and 0x5f8 and 0x600 tell the DCP from what offset in the structure input data to read a pointer and size from. The DCP then requests a memory mapping from the AP for that memory from the calling task: <a id="t.aba9dc90c6ed53b6789430b30f81bcfaea4d57c4"></a><a id="t.19"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> return wrap_MemoryDescriptor::withAddressRange(   *(void*)(structure_input_buffer + addr_offset),   *(unsigned int *)(structure_input_buffer + size_offset),   caller_task_ptr);</td></tr></table> We saw earlier that the AP sends the DCP the struct task pointer of the calling task; when the DCP requests a memory mapping from a user task it sends those raw task struct pointers back to the AP such that the kernel can perform the mapping from the correct task. The memory mapping is abstracted as an MDES object on the DCP side; the implementation of the mapping involves the DCP making an RPC to the AP: <a id="t.3170af9bf4e5590254e3fb8ce48d68439d2d1c04"></a><a id="t.20"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> make_link_call('D453', &req, 0x20, &resp, 0x14);</td></tr></table> which corresponds to a call to this method on the AP side: <a id="t.6497588dbb4a0e06e642bb1567a0fe45e731eabb"></a><a id="t.21"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> IOMFB::MemDescRelay::withAddressRange(unsigned long long, unsigned long long, unsigned int, task*, unsigned long*, unsigned long long*)</td></tr></table> The DCP calls ::prepare and ::map on the returned MDES object (exactly like an IOMemoryDescriptor object in IOKit), gets the mapped pointer and size to pass via a few final levels of indirection to the block handler: <a id="t.9bfd168ba40a9f143ab7f16183ab117679ba2dbc"></a><a id="t.22"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> a_descriptor_with_controlled_stuff->dispatcher_fptr(   a_descriptor_with_controlled_stuff,   block_type_handler,   important_ptr,   important_size);</td></tr></table> where the dispatcher_fptr looks like this: <a id="t.acd62f1b5ef2e8ae92523e3f984117951fec44d7"></a><a id="t.23"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> a_dispatcher(         struct metadispatcher *disp,         struct BlockHandler *block_handler,         __int64 controlled_ptr,         unsigned int controlled_size) {   return block_handler->BlockHandler_setBlock(            block_handler,            disp->structure_input_buffer,            disp->structure_input_size,            disp->remaining_scalar_inputs,            disp->cnt_remaining_sclar_input,            disp->handlers_holder->gate,            controlled_ptr,            controlled_size); }</td></tr></table> You can see here just how useful it is to keep making structure definitions while reversing; there are so many levels of indirection that it's pretty much impossible to keep it all in your head. BlockHandler_setBlock is a virtual method on BLHA. This is the implementation for BLHA 19: <a id="t.54f6196429ae58c591e0fbda962486be871b857c"></a><a id="t.24"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> BlockHandler19::setBlock(   struct BlockHandler *this,   void *structure_input_buffer,   int64 structure_input_size,   int64 *remaining_scalar_inputs,   unsigned int cnt_remaining_scalar_inputs,   struct CommandGate *gate,   void* mapped_mdesc_ptr,   unsigned int mapped_mdesc_length)</td></tr></table> This uses a Command Gate (GATI) object (like a call gate in IOKit to serialise calls) to finally get close to actually calling the setBlock_Impl function. We need to reverse the gate_context structure to follow the controlled data through the gate: <a id="t.ecbfc354e58e0a03f109ff9486e9e7688b91b2e0"></a><a id="t.25"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct __attribute__((aligned(8))) gate_context {  struct BlockHandler *the_target_this;  uint64_t structure_input_buffer;  void *remaining_scalar_inputs;  uint32_t cnt_remaining_scalar_inputs;  uint32_t field_28;  uint64_t controlled_ptr;  uint32_t controlled_length; };</td></tr></table> The callgate object uses that context object to finally call the BLHA setBlock handler: <a id="t.af3652c5bd10314e902473b353a7422786c1de2f"></a><a id="t.26"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> callback_used_by_callgate_in_block_19_setBlock(   struct UnifiedPipeline *parent_pipeline,   struct gate_context *context,   int64 a3,   int64 a4,   int64 a5) {   return context->the_target_this->setBlock_Impl)(            context->the_target_this->back_ptr_to_UPPipeDCP_H13P,            context->structure_input_buffer,            context->remaining_scalar_inputs,            context->cnt_remaining_scalar_inputs,            context->controlled_ptr,            context->controlled_length); }</td></tr></table><h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.3xz0wc9abhwz">SetBlock_Impl</h2> And finally we've made it through the whole callstack following the controlled data from IOConnectCallMethod in userspace on the AP to the setBlock_Impl methods on the DCP! The prototype of the setBlock_Impl methods looks like this: <a id="t.ce1b657ebc4685a8be9f9a3720b828c0f9a2d7ce"></a><a id="t.27"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> setBlock_Impl(struct UPPipeDCP_H13P *pipe_parent,               void *structure_input_buffer,               int *remaining_scalar_inputs,               int cnt_remaining_scalar_inputs,               void* ptr_via_memdesc,               unsigned int len_of_memdesc_mapped_buf)</td></tr></table> The exploit calls two setBlock_Impl methods; 7 and 19. 7 is fairly simple and seems to just be used to put controlled data in a known location. 19 is the buggy one. From the log strings we can tell that block type 19 handler is implemented in a file called UniformityCompensator.cpp. <a class="HovzfPYjjR-c191" href="https://www.benq.com/en-us/knowledge-center/knowledge/screen-uniformity.html">Uniformity Compensation</a> is a way to correct for inconsistencies in brightness and colour reproduction across a display panel. Block type 19 sets and gets a data structure containing this correction information. The setBlock_Impl method calls UniformityCompensator::set and reaches the following code snippet where controlled_size is a fully-controlled u32 value read from the structure input and indirect_buffer_ptr points to the mapped buffer, the contents of which are also controlled: <a id="t.7beb7cf889ce845693bd09783570df3d7b3034d3"></a><a id="t.28"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> uint8_t* pages = compensator->inline_buffer; // +0x24 for (int pg_cnt = 0; pg_cnt < 3; pg_cnt++) {   uint8_t* this_page = pages;   for (int i = 0; i < controlled_size; i++) {     memcpy(this_page, indirect_buffer_ptr, 4 * controlled_size);     indirect_buffer_ptr += 4 * controlled_size;     this_page += 0x100;   }   pages += 0x4000; }</td></tr></table> There's a distinct lack of bounds checking on controlled_size. Based on the structure of the code it looks like it should be restricted to be less than or equal to 64 (as that would result in the input being completely copied to the output buffer.) The compensator->inline_buffer buffer is inline in the compensator object. The structure of the code makes it look that that buffer is probably 0xc000 (three 16k pages) large. To verify this we need to find the allocation site of this compensator object. It's read from the pipe_parent object and we know that at this point pipe_parent is a UPPipeDCP_H13P object. There's only one write to that field, here in UPPipeDCP_H13P::setup_tunables_base_target: <a id="t.76bc35a503bf64e16502962e6e6a4632f74fe58f"></a><a id="t.29"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> compensator = CXXnew(0xC608LL); ... this->compensator = compensator;</td></tr></table> The compensator object is a 0xc608 byte allocation; the 0xc000 sized buffer starts at offset 0x24 so the allocation has enough space for 0xc608-0x24=0xC5E4 bytes before corrupting neighbouring objects. The structure input provided by the exploit for the block handler 19 setBlock call looks like this: <a id="t.ab31ebe17a793d09fa94c11be61a4134ecf08386"></a><a id="t.30"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1"> struct_input_for_block_handler_19[0x5F4] = 70; // controlled_size struct_input_for_block_handler_19[0x5F8] = address; struct_input_for_block_handler_19[0x600] = a_size;</td></tr></table> This leads to a value of 70 (0x46) for controlled_size in the UniformityCompensator::set snippet shown earlier. (0x5f8 and 0x600 correspond to the offsets we saw earlier in the subtype's table:  <2, 0, 0x5F8, 0x600>) The inner loop increments the destination pointer by 0x100 each iteration so 0x46 loop iterations will write 0x4618 bytes. The outer loop writes to three subsequent 0x4000 byte blocks so the third (final) iteration starts writing at 0x24 + 0x8000 and writes a total of 0x4618 bytes, meaning the object would need to be 0xC63C bytes; but we can see that it's only 0xc608, meaning that it will overflow the allocation size by 0x34 bytes. The RTKit malloc implementation looks like it adds 8 bytes of metadata to each allocation so the next object starts at 0xc610. How much input is consumed? The input is fully consumed with no "rewinding" so it's 3*0x46*0x46*4 = 0xe5b0 bytes. Working backwards from the end of that buffer we know that the final 0x34 bytes of it go off the end of the 0xc608 allocation which means +0xe57c in the input buffer will be the first byte which corrupts the 8 metadata bytes and +0x8584 will be the first byte to corrupt the next object: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTc6JqgJIYvcwLtg14PNyjGRL4ds-1hzVvPPYmuSbJ3TiMHTXI3loB4Ib4caBv06WwUAa2H3eEldnlVKePnyUDTxYy6-W0VyMbVSn1YrcilcuOmjeYPwzdQ0ONiWlZbc34oZBXv6hftbOK57Qu_NupLfhgI-Iqc9U51KfJVF5YRk4YmBFcYdoaH27q/s1888/Screenshot%202022-06-22%20at%2016.54.15.png" style="display: block; padding: 1em 0; text-align: center;"><img alt="A diagram showing that the end of the overflower object overlaps with the metadata and start of the target object." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTc6JqgJIYvcwLtg14PNyjGRL4ds-1hzVvPPYmuSbJ3TiMHTXI3loB4Ib4caBv06WwUAa2H3eEldnlVKePnyUDTxYy6-W0VyMbVSn1YrcilcuOmjeYPwzdQ0ONiWlZbc34oZBXv6hftbOK57Qu_NupLfhgI-Iqc9U51KfJVF5YRk4YmBFcYdoaH27q/s1200/Screenshot%202022-06-22%20at%2016.54.15.png" style="max-height: 750; max-width: 600px;" title="A diagram showing that the end of the overflower object overlaps with the metadata and start of the target object." /></a> This matches up exactly with the overflow object which the exploit builds: <a id="t.87397a57c7bdef65de5578925dd0ccccbdee255a"></a><a id="t.31"></a><table class="HovzfPYjjR-c20"><tr class="HovzfPYjjR-c18"><td class="HovzfPYjjR-c13" colspan="1" rowspan="1">   v24 = address + 0xE584;   v25 = *(_DWORD *)&v54[48];   v26 = *(_OWORD *)&v54[32];   v27 = *(_OWORD *)&v54[16];   *(_OWORD *)(address + 0xE584) = *(_OWORD *)v54;   *(_OWORD *)(v24 + 16) = v27;   *(_OWORD *)(v24 + 32) = v26;   *(_DWORD *)(v24 + 48) = v25;</td></tr></table> The destination object seems to be allocated very early and the DCP RTKit environment appears to be very deterministic with no ASLR. Almost certainly they are attempting to corrupt a neighbouring C++ object with a fake vtable pointer. Unfortunately for our analysis the trail goes cold here and we can't fully recreate the rest of the exploit. The bytes for the fake DCP C++ object are read from a file in the app's temporary directory (base64 encoded inside a JSON file under the exploit_struct_offsets key) and I don't have a copy of that file. But based on the flow of the rest of the exploit it's pretty clear what happens next:<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.wtkqcqujjnsf">sudo make me a DART mapping</h2> The DCP, like other coprocessors on iPhone, sits behind a DART (Device Address Resolution Table.) This is like an SMMU (IOMMU in the x86 world) which forces an extra layer of physical address lookup between the DCP and physical memory. <a class="HovzfPYjjR-c191" href="https://googleprojectzero.blogspot.com/2017/10/over-air-vol-2-pt-3-exploiting-wi-fi.html">DART was covered in great detail in Gal Beniamini's Over The Air - Vol. 2, Pt. 3 blog post</a>. The DCP clearly needs to access lots of buffers owned by userspace tasks as well as memory managed by the kernel. To do this the DCP makes RPC calls back to the AP which modifies the DART entries accordingly. This appears to be exactly what the DCP exploit does: the D45X family of DCP->AP RPC methods appear to expose an interface for requesting arbitrary physical as well as virtual addresses to be mapped into the DCP DART. The fake C++ object is most likely a stub which makes such calls on behalf of the exploit, allowing the exploit to read and write kernel memory.<h2 class="HovzfPYjjR-c15 HovzfPYjjR-c8" id="h.gkcey04fmfci">Conclusions</h2> Segmentation and isolation are in general a positive thing when it comes to security. However, splitting up an existing system into separate, intercommunicating parts can end up exposing unexpected code in unexpected ways. We've had discussions within Project Zero about whether this DCP vulnerability is interesting at all. After all, if the UniformityCompensator code was going to be running on the Application Processors anyway then the Display Co-Processor didn't really introduce or cause this bug. Whilst that's true, it's also the case that the DCP certainly made exploitation of this bug significantly easier and more reliable than it would have been on the AP. Apple has invested heavily in memory corruption mitigations over the last few years, so moving an attack surface from a "mitigation heavy" environment to a "mitigation light" one is a regression in that sense. Another perspective is that the DCP just isn't isolated enough; perhaps the intention was to try to isolate the code on the DCP such that even if it's compromised it's limited in the effect it could have on the entire system. For example, there might be models where the DCP to AP RPC interface is much more restricted. But again there's a tradeoff: the more restrictive the RPC API, the more the DCP code has to be refactored - a significant investment. Currently, the codebase relies on being able to map arbitrary memory and the API involves passing userspace pointers back and forth. I've discussed in recent posts how attackers tend to be ahead of the curve. As the curve slowly shifts towards memory corruption exploitation getting more expensive, attackers are likely shifting too. We saw that in the <a class="HovzfPYjjR-c191" href="https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html">logic-bug sandbox escape used by NSO</a> and we see that here in this memory-corruption-based privilege escalation that side-stepped kernel mitigations by corrupting memory on a co-processor instead. Both are quite likely to continue working in some form in a post-memory tagging world. Both reveal the stunning depth of attack surface available to the motivated attacker. And both show that defensive security research still has a lot of work to do.</body> <div style='clear: both;'></div> </div> <div class='post-footer'> <div class='post-footer-line post-footer-line-1'> Posted by <meta content='https://www.blogger.com/profile/08975904405228580347' itemprop='url'/> <a class='g-profile' href='https://www.blogger.com/profile/08975904405228580347' rel='author' title='author profile'> Google Project Zero </a> at <meta content='https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html' itemprop='url'/> <a class='timestamp-link' href='https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html' rel='bookmark' title='permanent link'><abbr class='published' itemprop='datePublished' title='2022-06-23T09:01:00-07:00'>9:01 AM</abbr></a> <a class='comment-link' href='https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html#comment-form' onclick=''> No comments: </a> <a href='https://www.blogger.com/post-edit.g?blogID=4838136820032157985&postID=5973748726134682294&from=pencil' title='Edit Post'> <img alt='' class='icon-action' height='18' src='https://resources.blogblog.com/img/icon18_edit_allbkg.gif' width='18'/> </a> <div class='post-share-buttons goog-inline-block'> <a class='goog-inline-block share-button sb-email' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=5973748726134682294&target=email' target='_blank' title='Email This'>Email This</a><a class='goog-inline-block share-button sb-blog' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=5973748726134682294&target=blog' onclick='window.open(this.href, "_blank", "height=270,width=475"); return false;' target='_blank' title='BlogThis!'>BlogThis!</a><a class='goog-inline-block share-button sb-twitter' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=5973748726134682294&target=twitter' target='_blank' title='Share to X'>Share to X</a><a class='goog-inline-block share-button sb-facebook' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=5973748726134682294&target=facebook' onclick='window.open(this.href, "_blank", "height=430,width=640"); return false;' target='_blank' title='Share to Facebook'>Share to Facebook</a><a class='goog-inline-block share-button sb-pinterest' href='https://www.blogger.com/share-post.g?blogID=4838136820032157985&postID=5973748726134682294&target=pinterest' target='_blank' title='Share to Pinterest'>Share to Pinterest</a> </div> </div> <div class='post-footer-line post-footer-line-2'> </div> <div class='post-footer-line post-footer-line-3'> </div> </div> </div> </div> </div></div> </div> <div class='blog-pager' id='blog-pager'> <a class='blog-pager-newer-link' href='https://googleprojectzero.blogspot.com/search?updated-max=2022-10-27T12:48:00-07:00&max-results=1&reverse-paginate=true' id='Blog1_blog-pager-newer-link' title='Newer Posts'>Newer Posts</a> <a class='blog-pager-older-link' href='https://googleprojectzero.blogspot.com/search?updated-max=2022-06-23T09:01:00-07:00&max-results=1' id='Blog1_blog-pager-older-link' title='Older Posts'>Older Posts</a> <a class='home-link' href='https://googleprojectzero.blogspot.com/'>Home</a> </div> <div class='clear'></div> <div class='blog-feeds'> <div class='feed-links'> Subscribe to: <a class='feed-link' href='https://googleprojectzero.blogspot.com/feeds/posts/default' target='_blank' type='application/atom+xml'>Posts (Atom)</a> </div> </div> </div></div> </div> </div> <div class='column-left-outer'> <div class='column-left-inner'> <aside> </aside> </div> </div> <div class='column-right-outer'> <div class='column-right-inner'> <aside> <div class='sidebar section' id='sidebar-right-1'><div class='widget BlogSearch' data-version='1' id='BlogSearch1'> <h2 class='title'>Search This Blog</h2> <div class='widget-content'> <div id='BlogSearch1_form'> <form action='https://googleprojectzero.blogspot.com/search' class='gsc-search-box' target='_top'> <table cellpadding='0' cellspacing='0' class='gsc-search-box'> <tbody> <tr> <td class='gsc-input'> <input autocomplete='off' class='gsc-input' name='q' size='10' title='search' type='text' value=''/> </td> <td class='gsc-search-button'> <input class='gsc-search-button' title='search' type='submit' value='Search'/> </td> </tr> </tbody> </table> </form> </div> </div> <div class='clear'></div> </div><div class='widget PageList' data-version='1' id='PageList1'> <h2>Pages</h2> <div class='widget-content'> <ul> <li> <a href='https://googleprojectzero.blogspot.com/p/about-project-zero.html'>About Project Zero</a> </li> <li> <a href='https://googleprojectzero.blogspot.com/p/working-at-project-zero.html'>Working at Project Zero</a> </li> <li> <a href='https://googleprojectzero.blogspot.com/p/0day.html'>0day "In the Wild"</a> </li> <li> <a href='https://googleprojectzero.github.io/0days-in-the-wild/rca.html'>0day Exploit Root Cause Analyses</a> </li> <li> <a href='https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html'>Vulnerability Disclosure FAQ</a> </li> </ul> <div class='clear'></div> </div> </div><div class='widget BlogArchive' data-version='1' id='BlogArchive1'> <h2>Archives</h2> <div class='widget-content'> <div id='ArchiveList'> <div id='BlogArchive1_ArchiveList'> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2025/'> 2025 </a> (2) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2025/01/'> January </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/'> 2024 </a> (12) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/12/'> December </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/11/'> November </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/10/'> October </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/06/'> June </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2024/04/'> April </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/'> 2023 </a> (11) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/11/'> November </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/10/'> October </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/09/'> September </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/08/'> August </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/04/'> April </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/03/'> March </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2023/01/'> January </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate expanded'> <a class='toggle' href='javascript:void(0)'> ▼  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/'> 2022 </a> (17) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/12/'> December </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/11/'> November </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/10/'> October </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/08/'> August </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate expanded'> <a class='toggle' href='javascript:void(0)'> ▼  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/06/'> June </a> (3) <ul class='posts'> <li><a href='https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html'>2022 0-day In-the-Wild Exploitation…so far</a></li> <li><a href='https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html'>The curious tale of a fake Carrier.app</a></li> <li><a href='https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html'>An Autopsy on a Zombie In-the-Wild 0-day</a></li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/04/'> April </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/03/'> March </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/02/'> February </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2022/01/'> January </a> (1) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/'> 2021 </a> (24) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/12/'> December </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/10/'> October </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/09/'> September </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/08/'> August </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/06/'> June </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/04/'> April </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/03/'> March </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/02/'> February </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2021/01/'> January </a> (10) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/'> 2020 </a> (36) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/12/'> December </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/11/'> November </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/10/'> October </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/09/'> September </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/08/'> August </a> (5) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/07/'> July </a> (8) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/06/'> June </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/04/'> April </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/02/'> February </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2020/01/'> January </a> (5) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/'> 2019 </a> (27) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/12/'> December </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/11/'> November </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/10/'> October </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/09/'> September </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/08/'> August </a> (11) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/04/'> April </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/03/'> March </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/02/'> February </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2019/01/'> January </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/'> 2018 </a> (22) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/12/'> December </a> (7) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/11/'> November </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/10/'> October </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/09/'> September </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/08/'> August </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/07/'> July </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/06/'> June </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/04/'> April </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2018/01/'> January </a> (1) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/'> 2017 </a> (19) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/12/'> December </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/10/'> October </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/09/'> September </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/08/'> August </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/07/'> July </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/04/'> April </a> (6) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/03/'> March </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2017/02/'> February </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/'> 2016 </a> (17) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/12/'> December </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/11/'> November </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/10/'> October </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/09/'> September </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/08/'> August </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/07/'> July </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/06/'> June </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/03/'> March </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/02/'> February </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2016/01/'> January </a> (1) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/'> 2015 </a> (33) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/12/'> December </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/11/'> November </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/10/'> October </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/09/'> September </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/08/'> August </a> (6) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/07/'> July </a> (5) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/06/'> June </a> (4) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/05/'> May </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/04/'> April </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/03/'> March </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/02/'> February </a> (3) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2015/01/'> January </a> (2) </li> </ul> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/'> 2014 </a> (11) <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/12/'> December </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/11/'> November </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/10/'> October </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/09/'> September </a> (1) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/08/'> August </a> (2) </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <a class='toggle' href='javascript:void(0)'> ►  </a> <a class='post-count-link' href='https://googleprojectzero.blogspot.com/2014/07/'> July </a> (3) </li> </ul> </li> </ul> </div> </div> <script type='text/javascript'> //<![CDATA[ (function(){ let archive_list = document.getElementById('ArchiveList'); if (archive_list == null) return; let cur_year = archive_list.querySelector('.post-count-link').innerText.trim() - 0; let last_year = 2014; let elements = []; const MONTHS = ',Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec'.split(','); let parent = document.getElementById('ArchiveList'); while (parent.childNodes.length) parent.removeChild(parent.childNodes[0]); function fetch_next_year() { let url = 'https://googleprojectzero.blogspot.com/?action=getTitles&widgetId=BlogArchive1&widgetType=BlogArchive&responseType=js&path=https%3A%2F%2Fgoogleprojectzero.blogspot.com%2F'+cur_year; fetch(url).then(resp => { if (!resp.ok) { console.log('http error'); return; } resp.text().then(text => { let scope = { _WidgetManager: { _HandleControllerResult: (name, method, results) => { elements.push(document.createElement('hr')); let year_header = document.createElement('div'); year_header.appendChild(document.createTextNode(cur_year)); year_header.style.fontSize = 'large'; elements.push(year_header); let list = document.createElement('ul'); elements.push(list); for (let obj of results.posts) { let link_parts = obj.url.split('/'); let year = link_parts[3]; let month = link_parts[4]; let el = document.createElement(/*'div'*/'li'); el.style.listStyleType = 'square'; el.style.listStylePosition = 'inside'; let link = document.createElement('a'); el.appendChild(link); link.appendChild(document.createTextNode(obj.title)); link.href = obj.url; let date_trailer = document.createElement('span'); el.appendChild(date_trailer); //date_trailer.appendChild(document.createTextNode(' ('+year+'-'+month+')')); date_trailer.appendChild(document.createTextNode(' ('+MONTHS[parseInt(month, 10)]+')')); //date_trailer.style.textAlign = 'right'; //elements.push(el); list.appendChild(el); } } } }; with (scope) { eval(text); } if (cur_year == last_year) { finish(); } else { cur_year--; fetch_next_year(); } }); }); } fetch_next_year(); function finish() { for (let obj of elements) { parent.appendChild(obj); } console.log(elements); } })(); //]]> </script> <div class='clear'></div> </div> </div></div> <table border='0' cellpadding='0' cellspacing='0' class='section-columns columns-2'> <tbody> <tr> <td class='first columns-cell'> <div class='sidebar no-items section' id='sidebar-right-2-1'></div> </td> <td class='columns-cell'> <div class='sidebar no-items section' id='sidebar-right-2-2'></div> </td> </tr> </tbody> </table> <div class='sidebar no-items section' id='sidebar-right-3'></div> </aside> </div> </div> </div> <div style='clear: both'></div>  </div>  </div> </div> <div class='main-cap-bottom cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> <footer> <div class='footer-outer'> <div class='footer-cap-top cap-top'> <div class='cap-left'></div> <div class='cap-right'></div> </div> <div class='fauxborder-left footer-fauxborder-left'> <div class='fauxborder-right footer-fauxborder-right'></div> <div class='region-inner footer-inner'> <div class='foot no-items section' id='footer-1'></div> <table border='0' cellpadding='0' cellspacing='0' class='section-columns columns-2'> <tbody> <tr> <td class='first columns-cell'> <div class='foot no-items section' id='footer-2-1'></div> </td> <td class='columns-cell'> <div class='foot no-items section' id='footer-2-2'></div> </td> </tr> </tbody> </table>  <div class='foot section' id='footer-3' name='Footer'><div class='widget Attribution' data-version='1' id='Attribution1'> <div class='widget-content' style='text-align: center;'> Powered by <a href='https://www.blogger.com' target='_blank'>Blogger</a>. </div> <div class='clear'></div> </div></div> </div> </div> <div class='footer-cap-bottom cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> </footer>  </div> </div> <div class='content-cap-bottom cap-bottom'> <div class='cap-left'></div> <div class='cap-right'></div> </div> </div> </div> <script type='text/javascript'> window.setTimeout(function() { document.body.className = document.body.className.replace('loading', ''); }, 10); </script> <script type="text/javascript" src="https://www.blogger.com/static/v1/widgets/1704033933-widgets.js"></script> <script type='text/javascript'> window['__wavt'] = 'AOuZoY7umr29N5ULdQt8WWDpXFYgLt22Sg:1740164165213';_WidgetManager._Init('//www.blogger.com/rearrange?blogID\x3d4838136820032157985','//googleprojectzero.blogspot.com/2022/06/','4838136820032157985'); _WidgetManager._SetDataContext([{'name': 'blog', 'data': {'blogId': '4838136820032157985', 'title': 'Project Zero', 'url': 'https://googleprojectzero.blogspot.com/2022/06/', 'canonicalUrl': 'https://googleprojectzero.blogspot.com/2022/06/', 'homepageUrl': 'https://googleprojectzero.blogspot.com/', 'searchUrl': 'https://googleprojectzero.blogspot.com/search', 'canonicalHomepageUrl': 'https://googleprojectzero.blogspot.com/', 'blogspotFaviconUrl': 'https://googleprojectzero.blogspot.com/favicon.ico', 'bloggerUrl': 'https://www.blogger.com', 'hasCustomDomain': false, 'httpsEnabled': true, 'enabledCommentProfileImages': true, 'gPlusViewType': 'FILTERED_POSTMOD', 'adultContent': false, 'analyticsAccountNumber': 'UA-240546891-1', 'encoding': 'UTF-8', 'locale': 'en', 'localeUnderscoreDelimited': 'en', 'languageDirection': 'ltr', 'isPrivate': false, 'isMobile': false, 'isMobileRequest': false, 'mobileClass': '', 'isPrivateBlog': false, 'isDynamicViewsAvailable': true, 'feedLinks': '\x3clink rel\x3d\x22alternate\x22 type\x3d\x22application/atom+xml\x22 title\x3d\x22Project Zero - Atom\x22 href\x3d\x22https://googleprojectzero.blogspot.com/feeds/posts/default\x22 /\x3e\n\x3clink rel\x3d\x22alternate\x22 type\x3d\x22application/rss+xml\x22 title\x3d\x22Project Zero - RSS\x22 href\x3d\x22https://googleprojectzero.blogspot.com/feeds/posts/default?alt\x3drss\x22 /\x3e\n\x3clink rel\x3d\x22service.post\x22 type\x3d\x22application/atom+xml\x22 title\x3d\x22Project Zero - Atom\x22 href\x3d\x22https://www.blogger.com/feeds/4838136820032157985/posts/default\x22 /\x3e\n', 'meTag': '', 'adsenseHostId': 'ca-host-pub-1556223355139109', 'adsenseHasAds': false, 'adsenseAutoAds': false, 'boqCommentIframeForm': true, 'loginRedirectParam': '', 'view': '', 'dynamicViewsCommentsSrc': '//www.blogblog.com/dynamicviews/4224c15c4e7c9321/js/comments.js', 'dynamicViewsScriptSrc': '//www.blogblog.com/dynamicviews/c320e3f9c6626331', 'plusOneApiSrc': 'https://apis.google.com/js/platform.js', 'disableGComments': true, 'interstitialAccepted': false, 'sharing': {'platforms': [{'name': 'Get link', 'key': 'link', 'shareMessage': 'Get link', 'target': ''}, {'name': 'Facebook', 'key': 'facebook', 'shareMessage': 'Share to Facebook', 'target': 'facebook'}, {'name': 'BlogThis!', 'key': 'blogThis', 'shareMessage': 'BlogThis!', 'target': 'blog'}, {'name': 'X', 'key': 'twitter', 'shareMessage': 'Share to X', 'target': 'twitter'}, {'name': 'Pinterest', 'key': 'pinterest', 'shareMessage': 'Share to Pinterest', 'target': 'pinterest'}, {'name': 'Email', 'key': 'email', 'shareMessage': 'Email', 'target': 'email'}], 'disableGooglePlus': true, 'googlePlusShareButtonWidth': 0, 'googlePlusBootstrap': '\x3cscript type\x3d\x22text/javascript\x22\x3ewindow.___gcfg \x3d {\x27lang\x27: \x27en\x27};\x3c/script\x3e'}, 'hasCustomJumpLinkMessage': false, 'jumpLinkMessage': 'Read more', 'pageType': 'archive', 'pageName': 'June 2022', 'pageTitle': 'Project Zero: June 2022'}}, {'name': 'features', 'data': {}}, {'name': 'messages', 'data': {'edit': 'Edit', 'linkCopiedToClipboard': 'Link copied to clipboard!', 'ok': 'Ok', 'postLink': 'Post Link'}}, {'name': 'template', 'data': {'name': 'custom', 'localizedName': 'Custom', 'isResponsive': false, 'isAlternateRendering': false, 'isCustom': true}}, {'name': 'view', 'data': {'classic': {'name': 'classic', 'url': '?view\x3dclassic'}, 'flipcard': {'name': 'flipcard', 'url': '?view\x3dflipcard'}, 'magazine': {'name': 'magazine', 'url': '?view\x3dmagazine'}, 'mosaic': {'name': 'mosaic', 'url': '?view\x3dmosaic'}, 'sidebar': {'name': 'sidebar', 'url': '?view\x3dsidebar'}, 'snapshot': {'name': 'snapshot', 'url': '?view\x3dsnapshot'}, 'timeslide': {'name': 'timeslide', 'url': '?view\x3dtimeslide'}, 'isMobile': false, 'title': 'Project Zero', 'description': 'News and updates from the Project Zero team at Google', 'url': 'https://googleprojectzero.blogspot.com/2022/06/', 'type': 'feed', 'isSingleItem': false, 'isMultipleItems': true, 'isError': false, 'isPage': false, 'isPost': false, 'isHomepage': false, 'isArchive': true, 'isLabelSearch': false, 'archive': {'year': 2022, 'month': 6, 'rangeMessage': 'Showing posts from June, 2022'}}}]); _WidgetManager._RegisterWidget('_NavbarView', new _WidgetInfo('Navbar1', 'navbar', document.getElementById('Navbar1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_HeaderView', new _WidgetInfo('Header1', 'header', document.getElementById('Header1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogView', new _WidgetInfo('Blog1', 'main', document.getElementById('Blog1'), {'cmtInteractionsEnabled': false, 'lightboxEnabled': true, 'lightboxModuleUrl': 'https://www.blogger.com/static/v1/jsbin/2332438401-lbx.js', 'lightboxCssUrl': 'https://www.blogger.com/static/v1/v-css/1964470060-lightbox_bundle.css'}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogSearchView', new _WidgetInfo('BlogSearch1', 'sidebar-right-1', document.getElementById('BlogSearch1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_PageListView', new _WidgetInfo('PageList1', 'sidebar-right-1', document.getElementById('PageList1'), {'title': 'Pages', 'links': [{'isCurrentPage': false, 'href': 'https://googleprojectzero.blogspot.com/p/about-project-zero.html', 'id': '4384467920505278144', 'title': 'About Project Zero'}, {'isCurrentPage': false, 'href': 'https://googleprojectzero.blogspot.com/p/working-at-project-zero.html', 'id': '2459334498880008057', 'title': 'Working at Project Zero'}, {'isCurrentPage': false, 'href': 'https://googleprojectzero.blogspot.com/p/0day.html', 'id': '3414239791814532209', 'title': '0day \x22In the Wild\x22'}, {'isCurrentPage': false, 'href': 'https://googleprojectzero.github.io/0days-in-the-wild/rca.html', 'title': '0day Exploit Root Cause Analyses'}, {'isCurrentPage': false, 'href': 'https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html', 'id': '2935252455704572784', 'title': 'Vulnerability Disclosure FAQ'}], 'mobile': false, 'showPlaceholder': true, 'hasCurrentPage': false}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogArchiveView', new _WidgetInfo('BlogArchive1', 'sidebar-right-1', document.getElementById('BlogArchive1'), {'languageDirection': 'ltr', 'loadingMessage': 'Loading\x26hellip;'}, 'displayModeFull')); _WidgetManager._RegisterWidget('_AttributionView', new _WidgetInfo('Attribution1', 'footer-3', document.getElementById('Attribution1'), {}, 'displayModeFull')); </script> </body> </html>